合并：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 -g（--use-merge-history）选项svn log并svn blame考虑合并跟踪。

  在Git和Mercurial中，在显示历史记录（日志）和责备时会自动考虑合并跟踪。在Git中，您可以请求仅跟随第一个父母--first-parent（我猜Mercurial也存在类似选项）以“丢弃”合并跟踪信息git log。

• 据我所知，svn:mergeinfo属性存储有关冲突的每路径信息（Subversion是基于变更集的），而在Git和Mercurial中，它只是可以拥有多个父级的提交对象。

• Subversion中合并跟踪的“已知问题”小节表明重复/循环/反射合并可能无法正常工作。这意味着在以下历史记录中，第二次合并可能不会做正确的事情（'A'可以是主干或分支，'B'可以分别是分支或主干）：

  * --- * --- x --- * --- y --- * --- * --- * --- M2 < -  A.
           \ / /
            -  * ---- M1 --- * --- * --- / < -  B.

  在上述ASCII艺术被破坏的情况下：分支'B'在修订版'x'处从分支'A'创建（分叉），然后分支'A'在修订版'y'处合并到分支'B'中合并'M1'，最后将分支'B'合并为分支'A'作为合并'M2'。

  * --- * --- x --- * ----- M1  -  * --- * --- M2 < -  A.
           \ / / 
            \  -  * --- y --- * --- * --- / < -  B.

  在上述ASCII艺术被破坏的情况下：分支'B'在修订版'x'处从分支'A'创建（分叉），它在'y'处合并为分支'A'作为'M1'，稍后再次合并为分支'A'作为'M2'。

• Subversion可能不支持纵向交叉合并的高级案例。

  * --- b ----- B1  -  M1  -  * --- M3
       / / / /
        \ X /
         \ / \ /
          \  -  B2  -  M2  -  *

  Git在实践中使用“递归”合并策略处理这种情况。我不确定Mercurial。

• 在“已知问题”中，警告合并跟踪不能与文件重命名一起使用，例如，当一方重命名文件（并且可能修改它）时，第二方修改文件而不重命名（在旧名称下）。

  Git和Mercurial在实践中都处理了这样的情况：Git使用重命名检测，Mercurial使用重命名跟踪。

HTH

Answer 2

在没有谈到通常的优点（离线提交，发布过程 ......）这里是一个我喜欢的“合并”示例：

我一直看到的主要场景是一个分支，其中...... 实际开发了两个不相关的任务
（它从一个功能开始，但它导致了另一个功能的开发。
或者它从一个补丁开始，但它导致了开发另一个功能）。

如何只合并主分支上的两个功能之一？
或者，您如何在自己的分支中隔离这两个功能？

您可以尝试生成某种补丁，问题是您不再确定可能存在的功能依赖关系：

• 补丁中使用的提交（或SVN修订版）

• 另一个承诺不是补丁的一部分

我认为Git（以及Mercurial）建议使用rebase --onto选项来重组（重置分支的根）部分：

- x - x - x (v2) - x - x - x (v2.1)
           \
            x - x - x (v2-only) - x - x - x (wss)

你可以解决这种情况，你有v2的补丁以及新的wss功能：

- x - x - x (v2) - x - x - x (v2.1)
          |\
          |  x - x - x (v2-only)
           \
             x - x - x (wss)

，允许您：

• 单独测试每个分支以检查所有内容是否按预期编译/工作

• 仅合并您想要的主要内容。

---

我喜欢的另一个功能（影响合并）是能够压缩提交（在尚未推送到另一个仓库的分支中）以呈现：

• 更清洁的历史

• 更一致的提交（而不是function1的commit1，function2的commit2，function1的commit3 ......）

这确保合并更容易，冲突更少。