我应该将 master 重新定位到已推送的分支上吗？

Question

我们在小型开发团队中使用feature branch workflow。我们目前正在开发一个大型项目，因此其中一位开发人员已将他们的功能分支推送到 origin，其他人都可以在其中签出自己的本地副本。

[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 的提交在那里，新的提交在 @ 987654339@ 正确地追随他们，但这是正确的方法吗？我应该如何继续，或者我应该使用不同的方法使responsive 与master 保持同步？

编辑：我制作了一个图表来更好地说明我的工作流程：

Answer 1

TLDR

我应该将 master 重新定位到已推送的分支上吗？

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

对于简单的功能分支，您可以在推送之前对它们进行变基（重写历史记录）。或者，至少，您可以确定只有一名开发人员使用功能分支并在您遇到 branches have diverged 情况时强制推送。

在responsive 分支的情况下，它是公开的并被许多开发人员使用。 所以你不能在 master 之上 rebase，做这个分支的常规合并。

注意：如 cmets 中所述，您的帖子中有一些令人困惑的术语。所以我假设...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

re-base 的流程：

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

如果只有一名开发人员在功能分支上工作，它会很好。 所以历史重写是安全的。

但是，当您添加 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 分支（另请参阅我的post 中的解释）。

您可以使用“-f”（强制）标志推送重新定位的responsive'，但是在responsive-feature-branch 上工作的开发人员会做什么呢？他只会拥有新的上游历史，并且必须相应地重写自己的本地历史。

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

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