dvcs部分合并(git,hg合并跟踪)

Question

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

在Git和Hg中,合并跟踪是在"提交"级别而不是"文件/目录"级别完成的.

其中一个"副作用"是您不能轻易进行"部分合并":

• 您已在分支"feature_branch_x"中修改了30个文件
• 你想只合并(让我们说)/ kernel/gui下的文件

使用"基于项目的合并跟踪"(Perforce,ClearCase,Plastic SCM <= 3.0),您可以选择要合并的几个文件,然后签入,然后重复合并,将显示待处理文件.

使用Hg,Git:一旦你合并(有方法保存文件而不合并),设置"跟踪",如果你重复合并,则不会留下合并的候选者.

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

是否存在您认为"部分合并"是强制性的情况？你可以没有它吗？(与commit/cset级别跟踪合并要快得多).

免责声明:我为Plastic SCM工作,我们已经转向4.0中的"cset"级别跟踪,但我们想知道保持"项目级别合并跟踪"或者两者兼而有之是不是一个好主意.

Answer 1

Mercurial 和 Git 的这种全树合并源于两者仅跟踪整树状态的哲学。Mercurial 和 Git 都无法在其元数据中存储部分合并的情况，因为这两个 SCM 都会跟踪合并的父级以及生成的树。这种观点的优点是，通过提交不成熟的合并而使存储库处于不稳定状态的可能性要小得多。

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

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