版本升级与版本分支的优缺点
在我当前的项目中，我必须决定在分支时使用哪种技术。 我有两个选择（我们假设我们已经决定在主干中开发）：
版本分支
每当新版本放到测试机器上时就创建一个分支，并将其标记为“release0.1”。 错误已在此分支中修复（当然，然后合并到主干），当此版本最终上线时，它被标记为“release0.1.1”。 这导致每个主要版本都有一个分支，每个次要版本都有一个标签。 如果必须在实时版本中修复错误，则将其修复在适当的分支中，然后合并到主干。
版本推广
只有三个分支“trunk”（用于开发）、“test”和“live”。 当版本放在测试机器上时，主干被合并（升级）到“test”分支，修复该分支中的错误，当版本发布时，“test”分支被合并到“live”分支。 如果我们在“实时”分支中发现错误，则会在那里修复它，然后合并到主干。
这两种哲学的优缺点是什么？ 您自己的经历是什么？ 还有其他可能更好的方法吗？
In my current project I have to decide which technique to use when branching. I have two options (we'll assume that we already have decided to develop in the trunk):
Version branches
Make a branch whenever a new version is put on the test machines and tag it like "release0.1". Bugs are fixed in this branch (and then merged to the trunk of course) and when this release finally goes live it's tagged "release0.1.1". This leads to having a branch for every major version and a tag for every minor version. If a bug has to be fixed in the live-version, it's fixed in it's appropriate branch and then merged down to the trunk.
Version promotion
Have only three branches "trunk" (for development), "test" and "live". When a version is put on the test machines, the trunk is merged (promoted) into the "test" branch, bugs are fixed in that branch and when the version is released, the "test" branch is merged into the "live" branch. If we find a bug in the "live" branch, it's fixed there and then merged down to the trunk.
What are the pros and cons of these two philosophies? What are your own experiences? Are there any other - possibly better - methods available?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这取决于您的维护政策。
如果您选择维护最新版本以上的版本（例如 XP 与 Vista 并行），版本分支是更好的选择。
It depends on your maintenance policy.
If you choose to maintain more than the latest release (XP in parallel to Vista for instance), version branches is a better choice.
根据我的经验，版本升级在合并来自不同分支的更改以及尝试记住哪个分支上修复的内容等方面的开销要小得多。因此，只要有可能，我更喜欢以这种方式工作。 不幸的是，如果您使用版本升级，通常无法对已发布的版本进行小的快速修复（因为有大量代码签入了“测试”分支）-> 所以我们有版本分支。
总而言之，我认为（至少对我来说）通常最好的方法是在两者之间做一些事情 - 在主干（主分支）上进行所有开发，标记所有构建/发布，并仅在需要时创建版本分支（例如，生产中存在严重错误，主干中存在无法发布的更改）。
From my experience version promotion has much smaller overhead on merging changes from different branches and trying to remember what was fixed on which branch, etc. so whenever possible I prefer to work this way. Unfortunately, if you use version promotion it is often not possible to do small quick fixes on the released version (because there are big chunks of code checked in to the "test" branch) -> so we and up having version branches.
To sum up I think (for me at least) usually the best way is to do something in-between the two - do all development on trunk (main branch), tag all builds/releases, and create a version branch only if needed (e.g. there is a critical bug in production, and there are changes in trunk that can't be released).
在我看来，两者是排他性的。
如果您必须维护不同的发布版本，则需要版本分支机制。 但我认为最好的做法是在发布版本后始终准备一个分支点（取决于您的管理版本系统）。
如果必须发布测试版本，就需要“升级”机制。 例如，如果您拥有一个不同于开发团队和/或开发速度很快的大型团队的验证团队，这将很有用。 在这些情况下，您需要一个特定的分支来稳定下一个“稳定”版本，同时主干保持“不稳定”。
In my opinion, the two are note exclusive.
The version branches mecanism is needed if you have to maintain different RELEASED versions. But I think it is a best-practice to always prepare a branching point (depending on your gestion version system) after releasing a version.
The "promotion" mecanism is needed if you have to release test version. This is usefull if you have, for example, a validation team distinct to development team and/or large team where development goes fast. In these cases, you need a specific branch to stabilize the next "stable" release while trunk stay "unstable".