“楼梯”有什么好处？ 分枝？
我遇到过一个使用楼梯分支的项目。 澄清一下，这是一种对代码进行分支以进行开发的方法，当开发完成时，开发分支被指定为实时代码集，并从中获取一个新分支，而不是切回主干/主线。 这会无限地持续下去。
我个人更喜欢削减到主干方法来维护一个“实时”代码集。 然而我想知道楼梯方法是否有任何令人信服的好处。
谢谢， 汤姆
I've encountered a project where we use staircase branching. To clarify, this is the approach where code is branched for development and when the development completes, rather than cutting back to a trunk/main line, the dev branch is designated as the live code set and a new branch is taken from it. This continues ad infinitum.
I personally prefer the cut back to a trunk approach to maintain one single "live" codeset. However I am wondering if there are any compeling benefits to the staircase approach.
Thanks,
Tom
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
当您想要创建多个分支并同时针对它们进行开发时，这种方法就会让您感到痛苦。 合并回主干可以让您拥有平行的分支，并轻松地将它们一次一个分支地合并在一起。
This method will bite you in the derriere the moment you want to create multiple branches and develop against them concurrently. Merging back to the trunk allows you to have parallel branches and easily bring them together one branch at a time.
我相信这是一种更容易回滚的方法，并且更清楚版本之间的差异。 继续开发以前的版本也更容易（例如，为开发人员提供一个版本，为设计人员提供一个版本）。
我自己更喜欢另一种带有指示检查点的标签的方法。 我使用 git，分支和做这类事情的过程用它构建得非常好。
I believe it's a way to make it easier to roll back, and a little clearer the differences between versions. It's also easier to continue developing a previous version (for instance, having a version for developers and a version for designers).
I myself prefer the other approach with tags indicating the checkpoints. I use git, and the process of branching and doing this kind of stuff is really well built with it.
从第一个楼梯开始，您就处于与开发第一个版本时相同的位置。 这就是它，没有关于将什么移回主干的后期决定。 楼梯上的建筑是您最新的候选者。
惩罚是，如果对原始版本进行大量更改和修复，您需要合并，这可能会造成破坏。 我猜测，当新版本的变化率和旧版本的补丁率使楼梯不理想时，可能会出现一个收支平衡点。
Right from the start of the first stair, you are in the same position as were when developing the first release. this is it, no late decisions about what to move back into the main trunk. The build from the stair is your latest candidate.
Penalty, if lots of change and fix in original you have merging up to do, and that might be disruptive. I'm guessing that there may be a break-even point when rate of change for the new release and rate of patch in the old make staircase suboptimal.
这种方法有几个（可能很小的）好处。
最引人注目的好处来自于不需要将更改合并回主分支。 这使得您可以轻松地为分支版本保留一个分支（旧的“主干”），并且不需要在开发分支上继续进行任何操作。 实际上，这与拥有一个实时主干并为发布进行标记或分支没有什么不同 - 只不过您“移动”您的开发而不是移动标记的分支。 这可以更轻松地以更少的精力维护干净的分支，因为不需要为每个版本“标记”新分支 - 它只是自动发生。 不过，这只是节省了一点时间。
但根据我的经验，有一个潜在的缺点。 我经常发现这种方法通常会让开发人员更容易意外地破坏库中的二进制兼容性，因为您总是在开发副本上工作，并且每个“版本”都是一个单独的分支。 由于合并回主干不需要任何努力，因此很容易意外破坏 API。 在我看来，这不是一个主要问题，但需要注意，因为在合并过程中没有付出任何努力（这似乎是大多数错误经常被发现的地方）。
There are a couple of (potentially minor) benefits to this approach.
The most compelling benefits arise from the lack of need to merge changes back into the main branch. This makes it easy to keep a branch (the old "trunk") for the version where you branched, as well as requiring no effort on the dev branch to continue on. In reality, this is no different than having one live trunk and tagging or branching out for a release, though - except that you "move" your development instead of moving your tagged branch. This can make it easier to maintain clean branches with less effort, since there's no need to "tag" a new branch for each release - it just kind of happens automatically. This is a minor timesavings, though.
In my experience, though, there is one potential disadvantage. I've often found that this approach often makes it easier for developers to accidentally break binary compatibility in libraries, since you're always working on a development copy, and each "release" is a separate branch from that. Since there's no effort required in merging back to a trunk, it can be easy to accidentally break an API. This isn't a major concern IMO, but is something to be aware of, since there is no effort during the merge process (which seems to be where most of these mistakes are often discovered).