颠覆背景:
我们正在从Subversion
过渡到Git
。
我们使用Subversion trunk
作为我们的"黄金副本",创建长期运行的功能分支,我们将trunk
合并多次分支。
最后,当功能完成后,我们会将分支合并回trunk
。
当我们这样做时,如果在Bar.java
中修改了trunk
,但我们从未在分支中对其进行修改,那么我们就永远不会在Bar.java
上发生合并冲突。
我相信这是因为Subversion
有一个svn:mergeinfo
的概念,并且知道合并的历史,并且Bar.java
从未在分支中修改过。
SVN分行维护图:
Git行为:
现在我们已经转换到Git
,即使我们没有在分支中更改Bar.java
,我们也会在将master与分支合并时遇到冲突!
我认为这是因为Git没有相同的svn:mergeinfo
概念,也没有跟踪Bar.java
来自master
并且已合并的事实。< / p>
Git Diagram(SHOWS ISSUE):
问题:
有没有什么方法可以继续使用我们在Subversion
中使用的相同方法(频繁合并trunk到branch)而不会在Git
中出现冲突?
有没有办法实现等效的svn:mergeinfo
,以便Git知道文件只在master
中更改而在branch
中从未更改过,并自动合并?
虽然我举例说明的例子很简单(一个文件),但实际上我们有许多开发人员并行工作并最终处理大量文件冲突,这种行为差异从svn
到{{1导致我们痛苦的很多。
答案 0 :(得分:0)
Git确实与svn:mergeinfo
类似,实际上更为先进。如果你看到你的分支中没有触及的文件的合并冲突意味着你确实以某种方式触摸它(IDE的自动行结束转换是一个常见的陷阱),或者有些重写了trunk上的历史记录。确保你们没有对{3}进行git rebase
,commit --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合并到当前分支的提交。