git
的合并冲突解决方案本质上比其他SCM(CVS,Subversion等)以及独立的合并工具更有效吗?如果是这样,为什么?
澄清:这里我对算法本身更感兴趣 - 它与普通的diff3方法有什么不同吗?
有些工具声称更聪明(例如Guiffy),是否值得将其作为git合并工具插入?
git是否更聪明地找出在文件内或跨文件移动的文本? (而不是报告嘈杂的冲突..我对Linus的谈话有一种模糊的印象)。
背景:刚刚使用git-svn
进行了大量合并,导致冲突的一半比我使用普通svn merge
(首次合并没有跟踪)产生的冲突..所以我想了解原因。
类似的Qs / As周围,但它们更多的是关于过程的大局,以及合并如何更自然地适应。为此,git
被'优化为合并'(而不仅仅是分支),它实际上意味着:
? 现在,我最感兴趣的是1& 2。
答案 0 :(得分:1)
我希望在这个答案上被证明是错误的,但......来自perforce ......这个git领域有点欠发达。
git中的自动合并是不存在的。最新版本基本支持使用您的更改或更改执行合并,但就是这样。基本上,如果您编辑文件的一部分而其他人编辑文件的相同部分...您可以自行进行合并解析。 diff3格式是可用的(3向合并),但我相信统一的diff格式是标准。我实际上使用araxis作为合并工具,并设置为在运行“git mergetool”时使用3路合并。来自perforce虽然...我觉得git在这方面落后了。
N / A
更新RE:评论
我没有深入研究git认为是冲突的确切内容,而且p4认为是冲突,但这是我在两者中所经历的。
我在这里的答案有点主观......但我非常想念我与perforce的合并。
答案 1 :(得分:1)
此外,这个more recent thread (2012)详细介绍了使用Git进行“自动解决”的概念:
我对“自动解决”的定义:
“在合并期间,更新工作树文件以反映合并的结果...当双方对同一文件的不同区域进行更改时,git选择两侧 在git完成合并提交后,自动将其留给您,以确保您查看这些合并结果的正确性。“IOW,“自动解决”具体意味着双方(我们和他们的)自
file(a)
的共同祖先版本以来对file(a)
进行了更改,并且git选择了双方而没有提升合并冲突。
(我提出“自动解决”一词的原因是因为在git-merge
输出中,术语“自动合并”也可以表示只有一方(他们的)改变了file(a)
-ancestor和那个git只是在共同祖先file(a)
之上“快速转发”他们file(a)
。)
Junio C Hamano提出了一个重要的观点:
- 知道 git是安全的愚蠢和错误,任何远程复杂的东西;
- 知道同一文件中出现的文本非冲突与不同文件之间存在语义冲突的风险相同,因此挑出“触及相同文件但没有冲突”的任何特殊情况都是没有意义的,但在任何一种情况下,发生这种冲突的可能性很小,以至于首先完成合并(和其他合并),然后检查整体结果是更有效地利用你的时间,因为你必须在推出结果之前至少观察一次结果。
更新5年半,2018年5月(Git 2.18,2018年第2季度)
“git mergetools
”学会了与guiffy交谈。
commit 6ceb658见Bill Ritcher (``)(2018年4月5日)
(Junio C Hamano -- gitster
--合并于commit da36be5,2018年4月25日)
mergetools:添加对
的支持guiffy
将
guiffy
添加为difftool
和mergetool
。
guiffy
可在Windows,Linux和MacOS上使用