在Mercurial中处理修补程序分支

我们当前的分支策略使用三个分支：

default

，

release

，

hotfix

hotfix

是从发布版分支出来的，然后在QA/测试之后，合并回

release

，然后再合并到

default

当下一个版本完成并且需要创建另一个修补程序时，我们应该使用最新的代码更新

修补程序

分支，还是从最新版本分支创建新的

修补程序

分支

---

我的本能是重新创建分支，以便更明确地了解何时以及为什么重新创建分支。但是，我不确定重新创建分支是否有任何缺点。

您可以为每个发行版/修补程序分支指定自己的名称，例如

v1.0.0

和

v1.0.0-hotfix

。在下一版本中，您可以关闭旧版本/修补程序分支

您还可以根据需要创建特定于热修复程序的分支。识别新的修补程序时，请为其指定名称和/或标识符，为其创建分支（例如，

hotfix-v1.0.0-001

）并制作修补程序。一旦它被接受，将其合并到

release

并关闭它

---

或者，如果您想保留当前的

发行版

/

修补程序

命名方案，在发布新产品时，将默认版本合并到发行版，然后再将发行版合并到修补程序。因为您已经将它们合并为默认值，所以不应该出现任何合并冲突。如果您这样做，您就知道要始终站在默认的一边。

在每次需要发布修补程序时，使用相同名称创建新分支是否存在任何缺点（从长远来看，性能方面）？或者维护单个

修补程序
分支是一种不常见的分支策略吗？@Omar我不确定一种方法与另一种方法的性能缺点。它们之间最大的区别是随着时间的推移最终得到的分支数量。我认为维护一个
发行版
分支或
修补程序
分支并不少见。从敏捷的角度来看，这样做是有意义的。潜在的优势：一个一致的概念有一个一致的分支名称，这样可以更容易地集成到一个持续的集成系统中。请注意，如果您在SourceTree中使用Git Flow，它只允许您一次创建一个修补程序分支，而不管分支名称如何。