git
的合并冲突解决本质上是否比其他 SCM(CVS、Subversion 等)以及独立的合并工具更有效?如果是这样,为什么?
澄清:这里我对算法本身更感兴趣——它与普通的 diff3 方法有什么不同吗?
有些工具声称在这方面更智能(例如 Guiffy),是否值得将其作为 git 合并工具插入?git 在确定文件内或文件间移动的文本方面是否更聪明?(而不是报告嘈杂的冲突。我从 Linus 的谈话中对此有一个模糊的印象)。
背景:刚刚进行了一次巨大的合并,使用git-svn
它导致的冲突比我使用普通的一半svn merge
(第一次合并没有跟踪)..所以我想了解原因。
它们是类似的 Qs/As,但它们更多的是关于过程的大图,以及合并如何更自然地适应。为此,git
“针对合并进行优化”(而不是仅分支),实际上是否意味着:
- 更少的手动冲突——更好的自动解析算法(例如,重命名处理得很好)
- 更安全的操作——自动解决留下更多/只有真正的冲突和更少的错误警报
- 更快的操作——比如说,由于精益和平均对象模型
- 更好的工具——这使得体验不那么痛苦,例如基于 DAG 的合并跟踪、mergetool、历史查询/可视化、stash、rebase 等...
- 别的东西
- 以上的组合
? 现在,我对 1 和 2 最感兴趣。