假设我有一个名为 feature 的分支，它已从 master 分支出来。 developer1 和 developer2 结帐feature。 developer1 提交对feature 的更改并推送它。然后 developer3 向master 推送一些东西。此时master 和feature 出现分歧，每个都有一个单独的提交。
如果有冲突，将最新的从 master 获取到 feature 的正确方法是什么？我应该将master 变基为feature，还是将其合并？
编辑：
我应该提到，在这种情况下，我不想重写 developer2 上的历史记录。因为那样会很糟糕。对吧？
【问题讨论】：
标签： git
考虑到feature 分支已经共享，它不应该基于master（因为它改变了它的-共享-历史）。
从master 到feature 的简单合并就足够了（无需推测为什么首先将dev3 推送到master）。
作为Adam Dymitrukcomments，这被称为“反向合并”，并且根据您赋予master的角色，这是值得怀疑的：如果master代表稳定的生产状态，您应该合并到 master，而不是来自 master。
但同样，我的回答没有假设所述角色。
这就是著名的 git-flow 在其 blog post 合并中说明的原因，这些合并将 到 master（例如，来自 hotfix 分支，如我commented earlier)
【讨论】：
git 是一个很棒的工具；但是，它不能代替开发人员之间的良好沟通。
您必须询问master 中的更改是否也必须包含在feature 中。理想情况下，功能分支应该有尽可能少的代码。
如果更改绝对必须包含在feature 中，那么您基本上有两个选择：git rebase；还有，git cherry-pick。我想你可以从master 向后合并到feature；但是，这可能会导致糟糕的情况......
cherry-pick 允许您对当前的HEAD 应用一个特定的提交或多个提交，保留评论和作者信息。在成功cherry-picked 之后，git 足够聪明，知道将feature 合并回master 时两个提交是相同的。如果只是我们所说的几个提交，那么cherry-pick 应该就足够了。
rebase 允许您从历史的不同点开始应用当前分支（提交行）。正如您所指出的，这对于已经拥有feature 副本的 developer1 和 developer2 来说可能很麻烦。他们还需要将rebase 本地开发转移到新 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-picking 的部分是在假设master 只有几个提交（或只有一个）并且它们都是cherry-picked 的情况下编写的。
x -- y (master)
\
a -- b -- c (feature)
【讨论】：
feature 分支上，并在未来合并feature 以合并可能更有问题？
bisects 并且功能分支不再只是功能。您关于采摘樱桃的观点非常有效。但是，我认为在master 上进行手术是处理这种情况的最佳方式。
hotfix 分支到feature 进行合并（如nvie.com/posts/a-successful-git-branching-model 所示），而不是master 到feature：我只是不知道dev3 从哪里做了他的/她的承诺。
第三位开发人员不应该在 master 上编写功能。罕见的例外是修补程序。但即便如此，它也应该是它自己的分支，然后与 --no-ff 合并到 master 上。我在这里写了一篇关于每个功能分支的长文：http://dymitruk.com/blog/2012/02/05/branch-per-feature/
【讨论】：