场景:
建立企业 Mercurial 系统。开发人员正在多个分支上工作，每个开发人员一个(或多或少)。我们大致遵循这种模型:https://www.mercurial-scm.org/wiki/ControlledPractice 。
设计/工作流程限制: repo 协议(protocol)是超长期的(10年以上)； repo 协议(protocol)上的开发人员数量在 10-30 范围内。
- DevA 修复了 1 个文件中的错误。
- DevB 需要固定文件，但明确不需要 DevA 的其余工作。
我们预计，这种情况将会发生很多次。
我可以想到几种方法来处理这种情况:
- Bugfix 位于单个变更集中，该变更集会从 DevA 的分支移植到 DevB 的分支(或共享代码分支)。
- 为修复生成一个命名分支，从 DevB 的开始提交生成，以便可以干净地 merge 。
问题:
- 重复的变更集可能会导致对给定功能的实现位置产生混淆(但也许不是？)。
- 在这个代码库上工作了几年之后，分支过多 = Not Acceptable 。
还有其他已知的方法来处理这种情况吗？
最佳答案
处理这个问题的方法是让 DevA 更加小心他的变更的父变更集。在 devA 提交 bug 修复之前，他/她应该hg update 到可能已进行该 bug 修复的最早版本(通常是引入该 bug 的变更集)。当开发人员 A 提交时，他/她将看到一条消息，说明已创建新头。然后可以将该新头拉出并 merge 到任何有错误的分支或存储库中，而无需携带任何其他内容。
关键是，当您拉取变更集时，您需要在存储库中包含您正在拉取的变更集的祖先的任何变更集，因此，如果您希望有人能够拉出修复程序，那么您'在不拉动您已完成的所有其他工作的情况下，您只需确保修复的父级是他们肯定已经拥有的变更集。
这确实需要开发人员稍微多一些深思熟虑，但比在存储库中使用不同的节点 ID 多次进行相同的更改更好，正如您所注意到的，这是有问题的(而且丑陋)。
这些新头就是一些人所说的“匿名分支”，它们不会像命名分支那样增殖。
关于mercurial - 在 hg 中共享单个文件的更改(而不是整个更改集)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5807668/