svn - 哪个版本控制工具最适合处理反射 merge 或循环 merge ？ SVN， git ？

Question

反射/循环 merge

这个最容易用一个例子来解释。假设您正在处理从主干复制的功能分支。在开发过程中，您定期将“所有”新更改从主干 merge 到您的分支，以便分支与主干上发生的工作保持“同步”。当您最终将分支 merge 回主干时，这称为反射(或循环) merge 。

请参阅 http://blogs.open.collab.net/svn/2008/07/subversion-merg.html 上的 Subversion merge reintegrate 文章更多细节。也可以引用http://jugalps.wordpress.com/2009/07/31/svn-branching-and-merging-in-scrum/以获得典型反射 merge 过程的概述。在处理此类场景时，我个人使用 SVN 的经验还不够好。

除了 SVN 之外，是否有人有使用任何其他版本控制工具进行反射 merge 的经验？

Answer 1

Git 在设计时一直考虑到了这种能力。这是我的第一个 VCS，对我来说，这种类型的工作流程完全是例行公事。一般来说， merge (推或请求 pull )回到原点(“主干”)是微不足道的，因为通过定期从原点 merge ，你已经确保你的 HEAD(分支尖端)在它的过去有原点的 HEAD，所以当原点 merge 你的工作，它只需要通过历史向前移动，而不是实际执行 merge (git 称之为“快进”)。

Git 的 rebase 功能也可以用来让历史变得更漂亮。如果你采用这个工作流程，你总是可以在你从源头提取的任何东西的基础上重新调整你的工作，而不是 merge 它们。 (这是重写历史，因此您必须确保不要对任何已发布的内容执行此操作)这样，您所有来自 origin 的 merge 都是快进的，并且您的工作只是 origin 的 HEAD 之上的单个提交序列。这使历史更加直接 - 希望是一条直线，而不是一系列的大量 merge 。