git的合并冲突解决方案比其他SCM和合并工具更有效吗?

时间:2010-06-23 22:26:04

标签: git version-control merge conflict 3-way-merge

git的合并冲突解决方案本质上比其他SCM(CVS,Subversion等)以及独立的合并工具更有效吗?如果是这样,为什么?

澄清:这里我对算法本身更感兴趣 - 它与普通的diff3方法有什么不同吗?
有些工具声称更聪明(例如Guiffy),是否值得将其作为git合并工具插入? git是否更聪明地找出在文件内或跨文件移动的文本? (而不是报告嘈杂的冲突..我对Linus的谈话有一种模糊的印象)。

背景:刚刚使用git-svn进行了大量合并,导致冲突的一半比我使用普通svn merge(首次合并没有跟踪)产生的冲突..所以我想了解原因。


类似的Qs / As周围,但它们更多的是关于过程的大局,以及合并如何更自然地适应。为此,git被'优化为合并'(而不仅仅是分支),它实际上意味着:

  1. 减少手动冲突 - 更好的自动分辨算法(例如,重命名处理得很好)
  2. 更安全的操作 - 自动解决方案留下更多/仅真正的冲突和更少的错误警报
  3. 更快的操作 - 比如,由于精益和平均对象模型
  4. 更好的工具 - 这使得体验减少痛苦,例如基于DAG的合并跟踪,合并工具,历史查询/可视化,存储,变基等...
  5. 别的东西
  6. 上述
  7. 的组合

    ? 现在,我最感兴趣的是1& 2。

2 个答案:

答案 0 :(得分:1)

我希望在这个答案上被证明是错误的,但......来自perforce ......这个git领域有点欠发达。

  1. git中的自动合并是不存在的。最新版本基本支持使用您的更改或更改执行合并,但就是这样。基本上,如果您编辑文件的一部分而其他人编辑文件的相同部分...您可以自行进行合并解析。 diff3格式是可用的(3向合并),但我相信统一的diff格式是标准。我实际上使用araxis作为合并工具,并设置为在运行“git mergetool”时使用3路合并。来自perforce虽然...我觉得git在这方面落后了。

  2. N / A

  3. 更新RE:评论

    我没有深入研究git认为是冲突的确切内容,而且p4认为是冲突,但这是我在两者中所经历的。

    • Git在进行合并时不会忽略空白区域...虽然git将来会讨论这个问题。 p4现在可以做到这一点。不要忽略空格是一个主要的痛苦,除非团队中的每个人都同意使用空格或制表符,如果你想改变文件的缩进...(例如在其他节点周围添加一个xml节点)那么这就快了
    • 我觉得当我遇到文件中的合并冲突时...... git所说的部分使用它的统一差异格式会发生冲突。当它只是一条线的一部分被改变时,它会将较大的部分标记为已修改,您需要在视觉上搜寻统一差异输出的两个区域之间的变化。你可以使用mergetool解决这个问题。即使编辑同一行,p4也能自动解决冲突。
    • 如果你正在合并长期存在的主题分支,那么你就是真正的享受。如果没有打开rerere(默认情况下是关闭的),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 6ceb658Bill Ritcher (``)(2018年4月5日) Junio C Hamano -- gitster --合并于commit da36be5,2018年4月25日)

  

mergetools:添加对guiffy

的支持      

guiffy添加为difftoolmergetool

     

guiffy可在Windows,Linux和MacOS上使用