Question

我听说过，例如将分支与git或mercurial合并比使用svn更容易。

在软件博客上阅读上一篇Joel，我并没有明白为什么。你能提供一个具体的例子，与svn相比，与git / mercurial合并会导致更少的合并冲突吗？

Answer 1

检查HGINIT。这是关于这个主题的Joel Spolsky（不是他最新的博客文章）的文章/教程。您可能会发现Subversion Re-Education部分特别有趣。

Answer 2

一个简单的例子是git可以自动将合并转换为“快进”。例如，假设我有一个看起来像这样的分支：

站长：

A ---> B ---> C

我创建了一个基于Master的功能分支，其中包含新的提交D和E.

特点：

A --- > B ---> C
                \
                 D ---> E

在svn中，当您将功能分支合并回主服务器时，您必须创建一个全新的提交，在主服务器上应用D和E的更改。所以，它看起来像：

Master:
    A ---> B ---> C -----------------> F
Feature:           \                  /
                    ---> D ---> E -->

在git中，我们可以选择如何将分支功能合并到master中。如果我们做了

git rebase feature

git会自动识别这是一个简单的合并并执行快进合并，这将把新的提交添加到主分支。 rebase的结果是：

站长：

A ---> B ---> C ---> D ---> E

Master和Feature的头部都指向提交E（换句话说，它们看起来完全相同）。快进合并类似于在svn中执行更新时发生的情况。

此外，您可以选择强制git创建合并提交。相反，我们这样做：

git merge feature

git将创建合并提交。合并的结果是：

Master:
    A ---> B ---> C -----------------> F
Feature:           \                  /
                    ---> D ---> E -->

提交F是D和E的组合。

Answer 3

Subversion只是方便地实现了单一的概念 - 恐惧分支。这意味着一个分支始终为parent，另一个分支为feature。功能可以随着时间的推移从父项中提取更新（合并），但父项只能将功能的更改拉一次（merge --reintegrate），然后应该关闭子项。在许多情况下这已足够，但并非总是如此。并非所有分支都是功能分支。我有几个例子。

首先。一个很好的例子是release branch。假设您正在准备基于经过全面测试的主干版本的版本。您从所需的主干版本中创建发布分支。现在，您不会受到任何后续主干修改的影响。但是您可能希望将修补程序提交到发布分支，并且您可能希望将这些修补程序反向移植到主干，而不关闭发布分支。这不能用svn的功能分支实现。使用svn，您将不得不等到不再需要发布分支，然后重新集成它。或者手动向后移植修补程序。
二。每个团队或每个开发人员的分支机构。没有一个很好的例子说明它们何时真正有用，但你肯定不会喜欢它们在svn中。同步这些分支会很痛苦。

Mercurial或git比svn对分支/合并有什么好处？

3 个答案: