我应该把主人变成一个被推的分支吗？

Question

我们在我们的小型开发团队中使用功能分支工作流程.我们目前正在开发一个大型项目,因此其中一位开发人员已将其功能分支推送到原点,其他人都可以查看他们自己的本地副本.

[leonard@dev public]$ git branch -avv
  master                        9d53b40 [origin/master] Fix reviews
* responsive                    0c04643 [origin/responsive] Add media queries
  remotes/origin/HEAD           -> origin/master
  remotes/origin/master         9d53b40 Fix reviews
  remotes/origin/responsive     0c04643 Add media queries

在master上进行开发时,我们创建了功能分支(即master_hotfix),然后当我们准备合并它时,我们首先将它们重新绑定master到它之前.这给了我们一个很好的线性历史,我们更喜欢.我们认为这也是使用我们的响应式项目执行此操作的最佳方式,因此我们将基于响应分支创建新分支(即responsive_some-feature).同样git pull,git rebase responsive responsive_some-feature也可以在这里使用.

但是我们对于我们是否应该(以及如果是这样,在什么时候)重新master投入使用感到困惑responsive？在responsive分支被推到之前origin,master对它的重新定位很简单,但是master要responsive重新定位responsive才能responsive_some-feature纠正？当我这样做时,我看到(以及一些冲突):

# On branch responsive
# Your branch and 'origin/responsive' have diverged,
# and have 112 and 109 different commit(s) each, respectively.
#
nothing to commit (working directory clean)

通常在这一点上,我看到一个干净的工作目录,然后我可以在那里签出master并合并我的功能分支.唉,在这个rebase之后,来自master那里的提交,新的提交responsive正好在它们之后,但是这是正确的方法？我该怎么办,或者我应该使用不同的方法来跟上responsive时间的关系master？

编辑:我已经制作了一个图形来更好地说明我的工作流程:

Answer 1

TLDR

我应该将master迁移到已推送的分支上吗？

不，您应该遵循一般规则- never rewrite the public history（=永远不要使已推送的分支变基）。

如果是简单的功能分支，则可以在推送之前对其进行基础更改（重写历史记录）。或者，至少，您可以确保只有一个开发人员可以使用功能分支，并在遇到branches have diverged情况时进行强制推送。

就responsive分支而言，它是公共的，并被许多开发人员使用。因此，您不能将其重新设置为master的基础，请对该分支进行常规合并。

注意：如评论中所述，您的帖子中的术语有些混乱。因此，我认为这...we first rebase master on to it [feature branch]...实际上意味着相反，并且您将功能分支重新建立在master之上。

说明

具有功能分支的“正常”（无历史记录）流如下所示：

1) we have a feature branch 

... O ---- O ---- A ---- B  master
                   \
                    C       feature-branch

2) we do the merge, usually with merge commit (D)
   sometimes it can be fast-forward without the merge commit

... O ---- O ---- A -- B -- D -  master
                   \       /
                    -- C --      feature-branch

用重库的流程：

1) we have a feature branch 

... O ---- O ---- A ---- B  master
                   \
                    C       feature-branch

2) we rebase feature branch on top of master
   note, that we changed the history and have new C' commit on 
   the feature branch

... O ---- O ---- A ---- B  master
                          \
                           C'  branch_xxx (feature branch)

3) we do the merge, master is fast-forwarded since there is nothing new
   on master

... O ---- O ---- A -- B -- C' -  master (fast forwarded)
                        \  /
                         C'      feature-branch

如果只有一个开发人员在Feature分支上工作，那就很好用。因此，历史记录重写是安全的。

但是，当您添加responsive分支时，据我了解，流程如下：

1) we have a feature branch 

... O ---- O ---- A ---- B       master
                   \
                    R1 -- R2     responsive
                           \
                            F1   responsive-feature-branch

2) now see what happens if `responsive-feature-branch` is still active (someone works on it) and we rebase the `responsive` on top of `master`:

... O ---- O ---- A ---- B                master
                  \       \
                   \       R1' -- R2'     responsive'
                    \
                     R1 -- R2             responsive
                            \
                             F1           responsive-feature-branch

看到问题了吗？现在您有两个responsive分支，它们是分开的（另请参见我的帖子中的说明）。

您可以responsive'使用“ -f”（强制）标志来推动重新设置，但是从事此工作的开发人员会responsive-feature-branch怎么做？他将只有新的上游历史记录，并且将不得不相应地重写自己的本地历史记录。

如果您确定没有人有派生的活动分支，responsive并且每个人都需要然后更新其本地存储库，则可以执行此强制更新。

但是我不建议这样做，因为您不能保证没有活动的子分支，总有一天您肯定会发现您的存储库已经搞砸了。我认为线性的历史记录不值得您花时间解决这些问题。