与 svn 相比，Mercurial 或 git 在分支/合并方面有哪些优势？
例如，我听说用 git 或 Mercurial 合并分支比用 svn 更容易。
阅读了 Joel 上一篇关于软件的博客文章，我不明白为什么。您能否提供一个具体示例，其中与 svn 相比，与 git/mercurial 合并会导致更少的合并冲突？
I've heard for instance that merging branches with git or mercurial is easier than with svn.
Reading last Joel on software blog entry, I didn't get it exactly why. Could you provide a concrete example where merging with git/mercurial lead to less merge conflicts compared to svn please?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一个简单的例子是 git 可以自动将合并转换为“快进”。例如，假设我有一个如下所示的分支：
Master:
A ---> B---> C我基于 Master 创建了一个功能分支，并添加了新的提交 D 和 E。
功能：
在 svn 中，当您将功能分支合并回 master 时，您必须创建一个全新的提交来应用 D 和 E 的更改。 E上师父。所以，它看起来像：
在 git 中，我们可以选择如何将分支功能合并到 master 中。如果我们执行
git 操作，它会自动识别出这是一个简单的合并并执行快进合并，这会将新的提交添加到 master 分支。 rebase的结果是：
Master：
Master和Feature的头都指向提交E（换句话说，它们看起来一模一样）。快进合并类似于在 svn 中进行更新时发生的情况。
此外，您可以选择强制 git 创建合并提交。如果我们这样做：
git 将创建一个合并提交。合并的结果是：
提交F是D和E的组合。
One simple example is git can automatically convert a merge into a "fast forward". For example, let's say I have a branch that looks like this:
Master:
A ---> B ---> CAnd I create a feature branch based on Master with new commits D and E.
Feature:
In svn, when you merge the feature branch back into master, you must create an entirely new commit that applies the changes of D and E on Master. So, it looks like:
In git we have a choice of how to incorporate the branch feature into master. If we do a
git will automatically recognize that this is a trivial merge and perform a fast-forward merge, which will add the new commits to the master branch. The result of the rebase is:
Master:
Both the head of Master and Feature point at commit E (in other words, they look exactly the same). A fast-forward merge is similar to what happens when you do an update in svn.
Additionally, you have the option of forcing git to create a merge commit. If instead we do:
git will create a merge commit. The result of the merge is:
Commit F is the combination of D and E.
检查 HGINIT 。这是 Joel Spolsky（不是他最新的博客文章）关于该主题的文章/教程。您可能会发现 Subversion Re-Education 部分特别有趣。
Check HGINIT out. It's an article/tutorial by Joel Spolsky (not his latest blog entry) on the topic. You might find the Subversion Re-Education part specially interesting.
Subversion 仅方便地实现了单一概念 - 分支分支。这意味着一个分支始终是
父级，另一个是功能。功能可以随着时间的推移从父级提取更新（合并），但父级只能提取功能的更改一次（合并-重新集成），然后应该关闭子级。在许多情况下它就足够了，但并非总是如此。并非所有分支都是功能分支。我有几个例子。发布分支。假设您正在准备一个基于经过彻底测试的主干修订版的版本。您从所需的主干修订版创建一个发布分支。现在您不会受到任何后续主干修改的影响。但是您可能希望将修补程序提交到发布分支，并且您可能希望将它们反向移植到主干而不关闭发布分支。这不能用 svn 的功能分支来实现。使用 svn，你必须等到不再需要你的发布分支，然后重新集成它。或者手动向后移植修补程序。Subversion conviniently implements only the single concept - fearure branches. This means one branch is always a
parentand the other isfeature. Feature can pull the updates from parent over time (merge), but parent can pull feature's changes only once (merge --reintegrate) and then the child should be closed. It is sufficient in many cases but not always. Not all branches are feature branches. I've got a couple of examples.release branch. Suppose, you're preparing a release based on a thoroughly tested trunk revision. You make a release branch from the desired trunk revision. Now you're not affected by any subsequent trunk modifications. But you may want to commit hotfixes to the release branch and you may want to backport those to trunk without closing the release branch. This cannot be implemented with svn's feature branches. With svn you will have to wait until your release branch is no longer needed and then reintegrate it. Or to backport the hotfixes by hand.