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

当你想要创建多个分支并同时针对它们进行开发时,这个方法会在混乱中咬你一口。合并回主干可以让您拥有平行的分支,并轻松地将它们一次合并到一个分支中。

我相信这是一种使回滚更容易的方法,并且版本之间的差异更清楚一点。继续开发以前的版本也更容易(例如,为开发人员提供一个版本,为设计人员提供一个版本)。

我自己更喜欢另一种方法,用标记来指示检查点。我使用Git,并且分支和做这种事情的过程是用它构建的。

从第一个楼梯开始,您与开发第一个版本时处于相同的位置。 这 是 它 ,没有关于将什么移回主干的延迟决定。楼梯上的建筑是你最新的候选人。

惩罚,如果在原始版本中进行大量的更改和修复,您就需要进行合并,这可能会造成破坏。我猜想,当新版本的变化率和旧版本的补丁率使楼梯变得次优时,可能会出现盈亏平衡点。

这种方法有几个(可能是次要的)好处。

最引人注目的好处来自于缺乏将变更合并回主分支的需求。这使得为分支所在的版本保留分支(旧的“主干”)变得容易,并且不需要对dev分支进行任何努力就可以继续。实际上,这与拥有一个活动的主干并为一个发布添加标签或分支没有什么不同,只是你“移动”了你的开发,而不是移动你的标记分支。这样就可以轻松地维护干净的分支,而不用太费劲,因为没有必要为每个版本“标记”一个新的分支——这只是一种自动发生的情况。不过,这只是一个小小的节省时间。

不过,根据我的经验,有一个潜在的缺点。我经常发现,这种方法常常使开发人员更容易意外地破坏库中的二进制兼容性,因为您总是在开发副本上工作,而每个“版本”都是与之不同的分支。由于合并回主干不需要做任何工作,因此很容易意外地破坏API。这不是IMO的主要关注点,但值得注意,因为合并过程中没有任何努力(这似乎是大多数错误经常被发现的地方)。