7

我有一个关于一般 DVCS 的问题，包括 Git 和 Hg。

在 Git 和 Hg 中，合并跟踪都是在“提交”级别而不是“文件/目录”级别完成的。

“副作用”之一是您不能轻易地进行“部分合并”：

  • 您已经修改了分支“feature_branch_x”中的 30 个文件
  • 您只想合并（比如说）/kernel/gui 下的文件

使用“基于项目的合并跟踪”（Perforce、ClearCase、Plastic SCM <= 3.0），您只需选择几个文件进行合并，然后签入，然后重复合并，待处理的文件就会显示出来。

使用 Hg，Git：一旦您合并（有一些方法可以在不合并的情况下保留文件），“跟踪”就会设置，如果您重复合并，则不会留下任何要合并的候选者。

我的问题是你感觉如何？？

是否存在您认为“部分合并”是强制性的情况？没有它你能活吗？（与提交/cset 级别跟踪合并要快得多）。

免责声明：我在Plastic SCM工作，我们已经在 4.0 中转移到“cset”级别跟踪，但我们想知道是否保留“项目级别合并跟踪”或者甚至允许两者都是一个好主意。

4

5 回答 5

4

我的感觉是，想要对分支进行部分合并表明一开始在一个分支中放了太多东西。处理这种情况的正确方法是将分支分成两个分支，从而纠正原始错误，而不是通过尝试跟踪部分合并来加剧错误。我更喜欢 SCM 功能，它使拆分分支更容易。

于 2011-09-06T18:10:46.547 回答
3

mercurial 和 Git 的这种全树合并来自两者的哲学，即只跟踪整棵树的状态。Mercurial 和 Git 都不能在其元数据中存储存在部分合并的情况，因为 SCM 都跟踪合并的父级以及生成的树。这种观点的优势在于，通过提交半生不熟的合并，不太可能使 repo 处于不稳定状态。

考虑一下文件从一个子目录移动到另一个子目录的情况，并且这些路径也被编码到源文件中。现在，当您仅合并子目录中的文件时，文件会在合并过程中正确移动，但源文件中的引用仍指向旧目录。当您现在提交此部分合并时，您在 VCS 中有一个失效状态。您需要以某种方式将最终合并提交标记为完成提交（我不知道塑料 SCM 是否具有这样的语义），以防止其他人检查这种正在进行的工作状态。

当然，将长期分流的分支合并是很讨厌的。在 DVCS 世界中，试图减轻这种怪物合并以合并早期和不断转移的分支（比如一个是特性分支，一个稳定的分支，经常合并稳定-> 特性是个好主意）。git 还能够跟踪合并冲突解决方案（称为rerere），这有助于在您尝试多次执行相同的合并时减轻合并的痛苦（例如何时在最终完成之前“练习”合并）。

于 2011-09-06T18:03:42.020 回答
2

Pablo，这是一个支持项目级合并的真实案例：让我们将主M分支设为客户分支C。该分支C是在不久前分叉的，可能是几周或几个月前，同时发生了M显着的变化。现在您需要为客户做一个热修复，从而修改C. 此外，您需要引入M.

我们的工作流程是对产品进行全面、适当的修复M、测试M和交付新的通用版本。然后我需要将修复的相关部分C合并到能够为受问题影响的客户提供自定义构建。因此，我需要将一些更改M从C. 这样的操作会有以下几个方面：

  • 一些文件“按原样”合并，
  • 一些文件是手动合并的，但是知道合并发生是非常重要的，
  • 合并的文件M不需要来自最新的变更集记录器M，它们可能跨越多个变更集。

因此，为了能够在检查存储库的历史记录时跟踪此类操作，文件之间的“数据（代码）流”应逐个文件记录。生成的“合并变更集”将包括 1:1 自动合并以及手动调整的合并。

更新：速度与可用性的权衡：据我了解，您的产品押注于非常好的合并等功能。而且我敢打赌，大多数用户不会关心超高速——但他们会关心一个非常好的合并。

大约十年前，将 1000 个文件添加到 ClearCase 需要 10 分钟。将它们添加到 Subversion 需要 1 分钟。这就是我们选择 Subversion 而不是 ClearCase 的原因。但是，如果 ClearCase 花费了 2 分钟，我们将（很可能）选择 ClearCase，因为它具有比当时更好的功能。

如果我获得了支持现实世界商业软件开发场景的良好工作功能，我将不在乎它是否会比我当前的 VCS（Subversion）快 50% 或慢 50%。但是，另一方面，如果与其他 VCS 工具相比，您提供的功能较差和/或可用性障碍，用户将不会切换。

总结一下变更集级别与项目级别的合并：坚持自由——至少从我的角度来看，这就是项目级别的合并。

于 2011-09-07T16:03:10.880 回答
1

从现在和以后合并一些文件：

考虑提交由子提交组成，每个子提交只更改一个文件，然后支持基于文件的操作。很明显，人们在分支/提交时不知道他们将来想要合并什么，这将解决这个问题。git 可以是内容和文件跟踪器。

于 2012-06-09T01:03:02.033 回答
0

恕我直言，为此获得分支/合并最“正确”的 SCM 是 PRCS，它支持具有完整每个项目历史的无痛部分合并。它允许您拥有诸如每个平台分支之类的东西并在它们之间合并，而不必担心特定于平台的更改“流血”到另一个分支中。这里描述了它使用的算法；

http://prcs.sourceforge.net/merge.html

我最想念的是基础和两个分支不同的合并，它会对每个文件进行三向合并，并且第一次会提示您输入“yours”、“theirs”或“merge”会记住您的响应作为下一次合并的默认值。

当我使用它时，我发现分支/合并非常轻松和直观，我一直在使用它们，而且从来没有觉得复杂。出于某种原因，使用 hg 和 git 进行分支/合并从未感觉如此轻松。

于 2017-12-11T02:13:40.857 回答