“楼梯”分支有什么好处？

Question

我遇到过一个使用楼梯分支的项目。为了澄清，这是代码为开发而分支的方法，当开发完成时，而不是切换回主干/主线，dev分支被指定为实时代码集，并从中获取新分支。这种情况无限期地持续下去。

我个人更喜欢削减到主干方法来维护一个单独的“实时”代码集。但是我想知道楼梯方法是否有任何令人感兴趣的好处。

谢谢， 汤姆

Answer 1

这个方法会在您想要创建多个分支并同时针对它们进行开发的那一刻咬你。合并回主干允许您拥有并行分支，并且可以轻松地将它们组合在一起。

Answer 2

我认为这是一种使回滚更容易的方法，并且更加清楚版本之间的差异。继续开发以前的版本也更容易（例如，开发人员版本和设计人员版本）。

我自己更喜欢使用标记指示检查点的其他方法。我使用git，分支和做这种东西的过程非常适合用它构建。

Answer 3

从第一个楼梯开始，您处于与开发第一个楼梯时相同的位置。 此 它，没有关于将什么移回主干线的迟到决定。楼梯的构建是你最新的候选人。

惩罚，如果有很多变化并且修复了原始的合并，那可能会造成破坏性。我猜测，当新版本的变化率和旧版楼梯中的补丁率不是最理想时，可能存在收支平衡点。

Answer 4

这种方法有一些（可能很小的）好处。

最引人注目的好处来自于无需将更改合并回主分支。这样可以很容易地为您分支的版本保留一个分支（旧的“主干”），并且不需要在dev分支上继续操作。实际上，这与一个实时主干和标记或分支发布没有什么不同 - 除了你“移动”你的开发而不是移动你的标记分支。这样可以更轻松地维护干净的分支，因为不需要为每个版本“标记”新分支 - 它只是自动发生。不过，这只是一个小小的节省时间。

但根据我的经验，有一个潜在的缺点。我经常发现这种方法通常会让开发人员更容易在库中意外地破坏二进制兼容性，因为你总是在开发副本，每个“发布”都是一个独立的分支。由于合并回主干无需任何工作，因此很容易意外破坏API。这不是IMO的主要关注点，但需要注意，因为在合并过程中没有任何努力（这似乎是经常发现大多数这些错误的地方）。