什么是使用共享特性分支的正确Git工作流程？

Question

假设我有一个名为feature的分支，它是从master分支中分离出来的。开发人员1和开发人员2都检出了feature。开发人员1对feature进行了更改并将其推送。然后开发人员3将某些内容推送到了master。此时，master和feature分岔，各自具有单独的提交。

如果存在冲突，正确的方法是如何将最新的master内容合并到feature中？我应该将master变基到feature中，还是将其合并？

编辑：我应该提到，在这种情况下，我不想重写开发人员2的历史记录。因为那样会很糟糕，对吗？

- gylaz

Answer 1

考虑到feature分支已经共享，不应该在master上进行变基（因为它会改变其-共享的-历史）。

从master到feature的简单合并就足够了（不要揣测dev3最初为什么要推送到master）。

正如Adam Dymitruk在评论中所说的那样，这被称为“回合并”，取决于您给master分配的角色，这是值得怀疑的：如果master代表稳定的生产状态，则应将合并到master，而不是从master合并。

但是，我的答案没有对所述角色做出任何假设。

这就是著名的git-flow为什么在其博客文章中说明来自to master的合并（例如，来自hotfix分支的合并，如我 先前评论的）

- VonC

---

回溯合并不好。无论其他开发者为什么向主分支提交了代码。 - Adam Dymitruk

Answer 2

git 是一款优秀的工具，但是它不能取代开发者之间良好的沟通。

你需要问自己，master 分支上的更改是否必须包含在 feature 分支中。理想情况下，功能分支 应该只包含最少量的代码。

如果这些更改绝对必须包含在 feature 分支中，那么你基本上有两个选择：git rebase 和 git cherry-pick。我想你也可以从 master 向后合并到 feature，但这可能会导致糟糕的情况...

cherry-pick 允许你将特定的提交或多个提交应用于当前的 HEAD，保留注释和作者信息。成功地进行了 cherry-pick 后，当将 feature 合并回 master 时，git 足够聪明以知道这两个提交是相同的。如果我们只谈论几个提交，那么 cherry-pick 应该就足够了。

rebase 允许你从历史的不同点开始应用当前分支（提交行）。就像你指出的那样，这可能会给已经拥有 feature 副本的 developer1 和 developer2 带来麻烦。他们还需要将自己的本地开发重新基于 新的 feature 分支。

无论如何，developer3 直接提交到 master 应该在其自己的功能分支中，然后将该功能分支合并。然后可以将该功能分支合并到 feature 中。假设只有一个（最近的）提交在 master 中，你可以按以下方式纠正这种情况：

# Ensure clean working directory
$ git stash

# Create new branch at master
$ git branch some-descriptive-name master

# Move master back one commit
$ git checkout master
$ git reset --hard HEAD^

# Merge the new branch into master
$ git merge --no-ff some-descriptive-name

# Forcibly update master
#   YOU SHOULD COMMUNICATE WITH OTHER DEVS BEFORE DOING THIS
$ git push -f origin master

# Merge the new branch into feature
$ git checkout feature
$ git merge --no-ff some-descriptive-name

我无法过分强调良好的沟通是多么重要，因为这些“意外”事情经常发生。祝你好运！

编辑：关于“cherry-pick”的部分是基于只有几个提交（或只有一个）到“master”，并且它们都将被“cherry-pick”的假设编写的。

x -- y (master)
 \
  a -- b -- c (feature)

- execjosh

---

我不喜欢 cherry-picking，因为它有限制（https://dev59.com/WXNA5IYBdhLWcg3wpfmu#881112），会复制 dev3 提交记录。我更倾向于进行合并。 - VonC

我理解，但是为什么要挑选这些提交，将它们复制到“feature”分支上，并使将来将“feature”合并回合并时可能更具问题性？ - VonC

如果你从主分支合并（反向合并），你会包含所有提交。这会导致非常冗长的 bisects，并且特性分支不再只是特性。你关于挑选某些提交的观点非常合理。但我认为对master进行手术是处理此情况的最佳方法。 - execjosh

正确。但在这种情况下，我们只谈论一个提交，对吗？ - VonC

点已经被接受了 ;) 但是，我仍然不喜欢从 master 到 feature 的那条线 :P - execjosh

有趣的是：主分支到特性分支的这条线，不知怎么就没让我感到困扰。我怀疑合并应该从一个“热修复”分支合并到“特性”分支（如http://nvie.com/posts/a-successful-git-branching-model/中所示），而不是从“主”分支合并到“特性”分支：我只是不知道`dev3`是从哪里提交的。 - VonC

Answer 3

第三个开发者不应该在主分支上编写功能。极少数情况下可以进行热修复，但即使如此，也应该是它自己的分支，然后使用--no-ff合并到主分支上。我在这里写了一篇关于每个功能分支的长文：http://dymitruk.com/blog/2012/02/05/branch-per-feature/

- Adam Dymitruk