Git将主服务器合并到分支 - 冲突(来自Subversion背景)

时间:2015-11-19 18:01:16

标签: git svn github version-control merge

颠覆背景:

我们正在从Subversion过渡到Git

我们使用Subversion trunk作为我们的"黄金副本",创建长期运行的功能分支,我们将trunk合并多次分支。

最后,当功能完成后,我们会将分支合并回trunk

当我们这样做时,如果在Bar.java中修改了trunk,但我们从未在分支中对其进行修改,那么我们就永远不会在Bar.java上发生合并冲突。

我相信这是因为Subversion有一个svn:mergeinfo的概念,并且知道合并的历史,并且Bar.java从未在分支中修改过。

SVN分行维护图:

SVN Branch Maintenence Diagram

Git行为:

现在我们已经转换到Git,即使我们没有在分支中更改Bar.java,我们也会在将master与分支合并时遇到冲突!

我认为这是因为Git没有相同的svn:mergeinfo概念,也没有跟踪Bar.java来自master并且已合并的事实。< / p>

Git Diagram(SHOWS ISSUE):

Git Diagram (SHOWS ISSUE)

问题:

有没有什么方法可以继续使用我们在Subversion中使用的相同方法(频繁合并trunk到branch)而不会在Git中出现冲突?

有没有办法实现等效的svn:mergeinfo,以便Git知道文件只在master中更改而在branch中从未更改过,并自动合并?

虽然我举例说明的例子很简单(一个文件),但实际上我们有许多开发人员并行工作并最终处理大量文件冲突,这种行为差异从svn到{{1导致我们痛苦的很多。

1 个答案:

答案 0 :(得分:0)

Git确实与svn:mergeinfo类似,实际上更为先进。如果你看到你的分支中没有触及的文件的合并冲突意味着你确实以某种方式触摸它(IDE​​的自动行结束转换是一个常见的陷阱),或者有些重写了trunk上的历史记录。确保你们没有对{3}进行git rebasecommit --amend或类似的历史记录重写更改。

编辑我们如何搜索mergeinfo

标准git log会在第二行显示合并信息:

$ git log
commit 1ca56fefd6ed1af2a6e62f1fbd811d56fa72ded7 (HEAD -> master, origin/master, origin/HEAD)
Merge: a3323f6 2237297

通常,您在UI上使用图形表示来查看已合并的内容以及未合并的内容。在命令行git log --oneline --graph HEAD origin/master将显示一个子图,其中包含您当前的workdir和origin/master以供检查。 git log origin/master --not HEAD会打印出git假定尚未从master合并到当前分支的提交。