合并：Hg / Git与SVN

Question

合并：Hg / Git与SVN

我经常读到Hg（和Git和......）在合并方面比SVN更好但是我从未见过Hg / Git可以合并SVN失败的地方（或者SVN需要人工干预的地方）的实际例子。您可以发布一些分支/修改/提交/ ....-操作的逐步列表，显示SVN在Hg / Git愉快地移动时会失败的位置吗？实用，非常特殊的情况请...

一些背景：我们有几十个开发人员在使用SVN进行项目，每个项目（或一组类似项目）都在自己的存储库中。我们知道如何应用发布和功能分支，所以我们不会经常遇到问题（即，我们一直在那里，但我们已经学会克服Joel的问题 “一个程序员给整个团队造成创伤”或“需要六个开发人员两周才能重新整合分支机构”）。我们的发布分支非常稳定，仅用于应用错误修正。我们的中继线应该足够稳定，能够在一周内创建发布。我们还有一些开发人员或开发人员可以使用的功能分支。是的，它们在重新集成后被删除，因此它们不会使存储库混乱。;）

所以我仍然试图找到Hg / Git优于SVN的优势。我很想获得一些实践经验，但是还没有任何更大的项目我们可以转移到Hg / Git，所以我一直在玩那些只包含一些组成文件的小型人工项目。而且我正在寻找一些你可以感受到Hg / Git令人印象深刻的力量的案例，因为到目前为止我经常读到它们但却未能自己找到它们。

Answer 1

我自己并没有使用Subversion，但是从Subversion 1.5的发行说明：合并跟踪（基础）看起来，在GID或Mercurial等全DAG版本控制系统中，合并跟踪的工作方式有以下不同之处。合并主干到分支不同于合并分支到主干：由于某种原因合并主干到分支需要--reintegrate选项svn merge。在像Git或Mercurial这样的分布式版本控制系统中，主干和分支之间没有技术差异：所有分支都是相同的（尽管可能存在社会差异）。在任一方向上合并都以相同的方式进行。您需要提供new&nbsp;-g（--use-merge-history）选项svn log并svn blame考虑合并跟踪。在Git和Mercurial中，在显示历史记录（日志）和责备时会自动考虑合并跟踪。在Git中，您可以请求仅跟随第一个父母--first-parent（我猜Mercurial也存在类似选项）以“丢弃”合并跟踪信息git log。据我所知，svn:mergeinfo属性存储有关冲突的每路径信息（Subversion是基于变更集的），而在Git和Mercurial中，它只是可以拥有多个父级的提交对象。Subversion中合并跟踪的“已知问题”小节表明重复/循环/反射合并可能无法正常工作。这意味着在以下历史记录中，第二次合并可能不会做正确的事情（'A'可以是主干或分支，'B'可以分别是分支或主干）：*&nbsp;---&nbsp;*&nbsp;---&nbsp;x&nbsp;---&nbsp;*&nbsp;---&nbsp;y&nbsp;---&nbsp;*&nbsp;---&nbsp;*&nbsp;---&nbsp;*&nbsp;---&nbsp;M2&nbsp;<&nbsp;-&nbsp;&nbsp;A. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\&nbsp;/&nbsp;/ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;*&nbsp;----&nbsp;M1&nbsp;---&nbsp;*&nbsp;---&nbsp;*&nbsp;---&nbsp;/&nbsp;<&nbsp;-&nbsp;&nbsp;B.在上述ASCII艺术被破坏的情况下：分支'B'在修订版'x'处从分支'A'创建（分叉），然后分支'A'在修订版'y'处合并到分支'B'中合并'M1'，最后将分支'B'合并为分支'A'作为合并'M2'。*&nbsp;---&nbsp;*&nbsp;---&nbsp;x&nbsp;---&nbsp;*&nbsp;-----&nbsp;M1&nbsp;&nbsp;-&nbsp;&nbsp;*&nbsp;---&nbsp;*&nbsp;---&nbsp;M2&nbsp;<&nbsp;-&nbsp;&nbsp;A. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\&nbsp;/&nbsp;/&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\&nbsp;&nbsp;-&nbsp;&nbsp;*&nbsp;---&nbsp;y&nbsp;---&nbsp;*&nbsp;---&nbsp;*&nbsp;---&nbsp;/&nbsp;<&nbsp;-&nbsp;&nbsp;B.在上述ASCII艺术被破坏的情况下：分支'B'在修订版'x'处从分支'A'创建（分叉），它在'y'处合并为分支'A'作为'M1'，稍后再次合并为分支'A'作为'M2'。Subversion可能不支持纵向交叉合并的高级案例。*&nbsp;---&nbsp;b&nbsp;-----&nbsp;B1&nbsp;&nbsp;-&nbsp;&nbsp;M1&nbsp;&nbsp;-&nbsp;&nbsp;*&nbsp;---&nbsp;M3 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/&nbsp;/&nbsp;/&nbsp;/ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\&nbsp;X&nbsp;/ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\&nbsp;/&nbsp;\&nbsp;/ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\&nbsp;&nbsp;-&nbsp;&nbsp;B2&nbsp;&nbsp;-&nbsp;&nbsp;M2&nbsp;&nbsp;-&nbsp;&nbsp;*Git在实践中使用“递归”合并策略处理这种情况。我不确定Mercurial。在“已知问题”中，警告合并跟踪不能与文件重命名一起使用，例如，当一方重命名文件（并且可能修改它）时，第二方修改文件而不重命名（在旧名称下）。Git和Mercurial在实践中都处理了这样的情况：Git使用重命名检测，Mercurial使用重命名跟踪。HTH

Answer 2

在没有谈到通常的优点（离线提交，发布过程&nbsp;......）这里是一个我喜欢的“合并”示例：我一直看到的主要场景是一个分支，其中......&nbsp;实际开发了两个不相关的任务（它从一个功能开始，但它导致了另一个功能的开发。或者它从一个补丁开始，但它导致了开发另一个功能）。如何只合并主分支上的两个功能之一？或者，您如何在自己的分支中隔离这两个功能？您可以尝试生成某种补丁，问题是您不再确定可能存在的功能依赖关系：补丁中使用的提交（或SVN修订版）另一个承诺不是补丁的一部分我认为Git（以及Mercurial）建议使用rebase --onto选项来重组（重置分支的根）部分：-&nbsp;x&nbsp;-&nbsp;x&nbsp;-&nbsp;x&nbsp;(v2)&nbsp;-&nbsp;x&nbsp;-&nbsp;x&nbsp;-&nbsp;x&nbsp;(v2.1) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x&nbsp;-&nbsp;x&nbsp;-&nbsp;x&nbsp;(v2-only)&nbsp;-&nbsp;x&nbsp;-&nbsp;x&nbsp;-&nbsp;x&nbsp;(wss)你可以解决这种情况，你有v2的补丁以及新的wss功能：-&nbsp;x&nbsp;-&nbsp;x&nbsp;-&nbsp;x&nbsp;(v2)&nbsp;-&nbsp;x&nbsp;-&nbsp;x&nbsp;-&nbsp;x&nbsp;(v2.1) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|\ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;x&nbsp;-&nbsp;x&nbsp;-&nbsp;x&nbsp;(v2-only) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x&nbsp;-&nbsp;x&nbsp;-&nbsp;x&nbsp;(wss)，允许您：单独测试每个分支以检查所有内容是否按预期编译/工作仅合并您想要的主要内容。我喜欢的另一个功能（影响合并）是能够压缩提交（在尚未推送到另一个仓库的分支中）以呈现：更清洁的历史更一致的提交（而不是function1的commit1，function2的commit2，function1的commit3 ......）这确保合并更容易，冲突更少。