假设我有一个名为feature已分支的分支master。developer1 和 developer2 checkout feature。developer1 提交更改feature并推送它。然后 developer3 推送一些东西到master. 在这一点上master并feature分歧，每个人都有一个单独的提交。
如果存在冲突，从master中获取最新信息的正确方法是什么？feature我应该master重新加入feature，还是合并它？
编辑：
我应该提一下，在这种情况下，我不想重写 developer2 上的历史记录。因为那样会很糟糕。正确的？
考虑到feature分支已经共享，它不应该被重新基于master（因为它改变了它的 - 共享 - 历史）。
master一个简单的从to合并feature就足够了（不用推测为什么首先要dev3推到master）。
正如Adam Dymitruk 评论的那样，这被称为“反向合并”，并且根据您归因于 的角色master，这是有问题的：如果master代表稳定的生产状态，您应该合并到 master，而不是from master。
但同样，我的回答没有假设所述角色。
这就是为什么著名的git-flow在其博客文章中说明了即将掌握的合并（例如，来自一个hotfix分支，正如我之前评论的那样）
git是一个很棒的工具；但是，它不能代替开发人员之间的良好沟通。
您必须询问 中的更改是否也master 必须包含在feature. 理想情况下，功能分支应该具有尽可能少的代码量。
如果更改绝对必须包含在 中feature，那么您基本上有两种选择git rebase：并且，git cherry-pick。master我想你可以从into执行向后合并feature；但是，这可能会导致糟糕的情况......
cherry-pick允许您将特定提交或多个提交应用于当前HEAD，保留评论和作者信息。成功cherry-picked 后，git 足够聪明，可以知道两个提交在合并feature回master. 如果只是我们正在谈论的几个提交，那么cherry-pick应该就足够了。
rebase允许您从历史的不同点开始应用当前分支（提交行）。正如您所指出的，这对于已经拥有feature. 他们还需要将rebase他们的本地开发转移到新 feature的分支上。
无论如何，masterdeveloper3 直接提交的内容应该在它自己的功能分支中，并且该功能分支应该已经合并。然后可以根据需要合并该功能分支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)
第三个开发人员不应该在 master 上编写功能。罕见的例外是修补程序。但即便如此，它应该是它自己的分支，然后合并--no-ff到 master 上。我在这里写了一篇关于每个功能分支的长文：http: //dymitruk.com/blog/2012/02/05/branch-per-feature/