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

Question

我在源代码管理中出现了一个相当罕见的问题。在此处的示例中，Perforce 出现了问题，但我怀疑许多 SCM 也会出现同样的问题，尤其是分布式 SCM。

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

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

Perforce 支持多个更改列表。基本上，当您 checkout 一个文件时，您会告诉它它属于哪个更改列表。因此，如果您正在开发花哨的新电子邮件功能，这将需要数月的工作并赚取数百万美元，并且技术支持人员向您提出必须在昨天修复的错误，您不必从整个项目的一个新分支。您可以将有缺陷的文件 checkout 到新的更改列表中，修复问题， checkin 新的更改列表，然后回到新电子邮件功能的实际工作中，就好像什么都没发生一样。

在大多数情况下，一切都很好。但是，当您实现电子邮件功能时，您会在所有地方进行无数次更改，尤其是在 main.h 中，而碰巧的是，当您开始修复错误时，您会发现必须进行的微小更改也在main.h中。新功能的更改列表已经 checkout 了 main.h，因此您不能轻易将其放入更改列表中以进行错误修复。

现在你做什么？你有几个选择:

创建一个新的客户端规范。 Perforce 中的 clientspec 是 depot 中的文件/目录列表以及要复制所有内容的本地目的地。因此，您可以创建项目的第二个副本，而无需对电子邮件功能进行任何更改。

做一个软糖。备份您修改后的 main.h 副本并恢复此文件。然后，您可以自由地将 main.h check out 到错误修复更改列表中。您修复错误， checkin 错误修复更改列表，然后将 main.h checkin 电子邮件功能更改列表。最后，您从一开始所做的备份中合并所有更改。

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

选项 1 可能是最干净的，但并不总是实用的。我正在处理的一个项目有数百万行代码和一个非常复杂的构建过程。设置一个新环境需要一天的时间，所以 5 分钟的 bug 修复是不切实际的。

选项 3 是一个糟糕的选项，但它是最快的，所以它可能非常诱人。

这留下了选项 2，这是我通常会使用的选项。

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

对于这个冗长的问题，我深表歉意，但我在 StackOverflow 上发现，经过深思熟虑的问题可以得到更好的答案。

Answer 1

这个确切的问题被称为“纠结的工作副本问题”。 Ryan Tomayko 有一篇博客文章，标题为 The Thing About Git详细讨论了这个问题以及 Git 如何解决它。

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