假设我有一个名为feature
的分支已经分支master
。 developer1和developer2 checkout feature
都是。 developer1将更改提交到feature
并推送它。然后developer3将某些内容推送到master
。此时master
和feature
分歧,每个都有一个单独的提交。
如果存在冲突,将master
的最新信息发送到feature
的正确方法是什么?我应该将master
重新加入feature
,还是将其合并?
修改
我应该提一下,在这种情况下,我不想重写developer2上的历史记录。因为那会很糟糕。正确?
答案 0 :(得分:3)
考虑到feature
分支已经共享,它不应该在master
上进行重新定位(因为它会更改其 - 共享 - 历史记录)。
从master
到feature
的简单合并就足够了(没有推测为什么dev3
首先推送到master
。
作为Adam Dymitruk comments,这被称为“反向合并”,并且,根据您归因于master
的角色,这是值得怀疑的:如果master
表示稳定的生产状态,您应该将合并到 master
,而不是 master
中的。
但是,我的回答再次没有假设这个角色。
这就是为什么着名的 git-flow 在其blog post合并中说明了到 master(例如,来自{{} 1}}分支,如commented earlier)
答案 1 :(得分:2)
git
是一个很棒的工具;但是,不能取代开发人员之间良好的沟通。
您必须询问master
中的更改是否必须也包含在feature
中。理想情况下,功能分支应该具有尽可能少的代码。
如果变更绝对必须包含在feature
中,那么您基本上有两个选项:git rebase
;并且,git cherry-pick
。我想您可以执行从master
到feature
的向后合并;但是,这可能导致糟糕的情况...
cherry-pick
允许您将特定提交或多次提交应用于当前HEAD
,保留评论和作者信息。在成功cherry-pick
ed之后,git足够聪明,知道在将feature
合并回master
时两个提交是相同的。如果只是我们谈论的一些提交,那么cherry-pick
就足够了。
rebase
允许您从历史记录中的不同点开始应用当前分支(提交行)。正如您所指出的,对于已经拥有feature
副本的developer1和developer2来说,这可能会很麻烦。他们还需要rebase
他们的本地开发到 new 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
ing的部分是在假设只有少数提交(或只有一个)到master
的情况下编写的,并且它们都将被cherry-pick
编辑。
x -- y (master)
\
a -- b -- c (feature)
答案 2 :(得分:1)
第三个开发人员不应该在master上编写一个功能。罕见的例外是修补程序。但即使这样,它应该是它自己的分支然后与--no-ff
合并到master上。我在这里写了一篇关于每个功能分支的长篇文章:http://dymitruk.com/blog/2012/02/05/branch-per-feature/