version-control - 处理源代码管理系统中的多个变更集

我在源代码管理中很少遇到问题。在此处的示例中，Perforce出现了问题，但是我怀疑许多SCM(尤其是分布式SCM)也会出现相同的问题。

Perforce支持变更列表(或您愿意的变更集)。变更列表支持两种常见用法:

当您提交变更列表时，该提交是原子性的，因此所有文件都已提交或没有提交。这是大多数人在提及变更列表时所谈论的标题功能。

Perforce支持多个变更列表。基本上，当您 checkout 文件时，便告诉它属于哪个变更列表。因此，如果您要使用花哨的新电子邮件功能，该功能将花费数月的时间并且可以赚到数百万美元，并且某位技术支持人员出现了必须在昨天修复的错误，那么您不必从头开始。整个项目的新分支。您可以将错误的文件 check out 到新的更改列表中，解决问题，检入新的更改列表，然后返回新电子邮件功能的实际工作，好像什么都没发生。

在大多数情况下，一切都很好。但是，当您实现电子邮件功能时，您到处都会进行数不胜数的更改，尤其是在main.h中，并且碰巧发生在进行错误修复时，您发现必须进行的微小更改也位于main.h中。新功能的变更列表已经 check out 了main.h，因此您无法轻松地将其放入变更列表中以进行错误修复。

现在你该怎么办？您有几种选择:

创建一个新的clientspec。 Perforce中的clientspec是仓库中文件/目录的列表，以及将要复制所有内容的本地目标。因此，您可以创建项目的第二个副本，而无需更改电子邮件功能。

做个软糖。备份修改后的main.h副本并还原此文件。然后，您可以将main.h checkout 到错误修正更改列表中。您修复了该错误，检入了错误修正更改列表，然后将main.h check out 到电子邮件功能更改列表中。最终，您将合并您在开始时所做的备份中的所有更改。

您确定对main.h所做的所有更改都没有副作用或依赖性，因此您只需将main.h移至错误修正更改列表中，进行更改并检入即可。然后再次将其 check out 到电子邮件中功能变更列表。显然，这种方法存在两个问题:首先，实际上可能存在您没有考虑过的副作用，其次，您已经破坏了版本的历史。

选项1可能是最干净的，但并不总是实用的。我正在从事的一个项目包含数百万行代码和一个非常复杂的构建过程。设置新环境需要一天的时间，因此5分钟的错误修复实际上并不实用。

选项3是一个不好的选择，但是它是最快的，因此非常诱人。

剩下的选项2是我通常会使用的选项。

有人有更好的解决方案吗？

我对冗长的问题表示歉意，但是我在StackOverflow上发现，完全思考问题会得出更好的答案。

最佳答案

这个确切的问题被称为“缠结工作副本问题”。 Ryan Tomayko有一个名为The Thing About Git的博客条目，它详细讨论了此问题以及Git如何解决该问题。

这是关于Git的最好的事情之一。我至少每天使用git add -p来帮助提交彼此独立的有意义的代码块。在同一个源文件中存在两个逻辑上不同的更改，这一事实变得无关紧要。

关于version-control - 处理源代码管理系统中的多个变更集，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/449642/