在 Web 应用程序的开发/维护过程中我应该使用什么分支策略？
我正在尝试为 Web 应用程序项目确定最佳分支策略。这是我到目前为止所想出的，我将非常感谢任何评论和经验。
在我看来，有两种主要的分支策略：“按版本分支”和“按功能分支”。
“按版本分支”：开发在主干上进行。当发布时间临近时，就会为该版本创建一个分支。然后对该分支进行稳定/测试，最后发布。发布后，分支会合并回主干，同时保持发布分支处于活动状态以修复错误。是否应用了错误修复，然后将其合并到主干中（如果主干上的开发没有以其他方式掩盖该错误）。新功能添加到主干，不会影响发布分支。 当新的发布时间临近时，会创建一个新的发布分支
“按功能分支”：主干始终是“生产”主干（实时代码）。错误修复直接提交到主干。下一个版本的功能是在功能分支中开发的。错误修复会不时合并到功能分支中。当发布时间到来时，功能分支将合并到主干中，生命周期将继续。
现在，我认为这两种策略之间最大的实际区别在于，“按发布”允许您维护软件的不同生产版本（当客户端 A 具有版本 1 且客户端 B 版本 1.5 时，客户端是此中的付费客户）案件）。相反，使用“按功能”策略，您只能支持当前的生产版本（所有客户端都使用最新版本）。
由于在典型的 Web 应用程序中，所有客户端都使用相同的“最新”版本（因为它们都访问同一服务器），因此我认为“按功能”方法是最常用的。它消除了“跨层次结构”合并的需要，比如当错误修复必须应用于所有 3 个发行版本时。
所以我目前的状态是我应该选择“按功能分支”。如果重要的话，我的团队技术不太好。
I am trying to decide on the best branching strategy for a web application project. Here is what I have come up with until now and I would greatly appreciate any comments and experiences.
The way I see it there are two main branching strategies: "branch by release" and "branch by feature".
"Branch by release": Development takes place on the trunk. When the time for a release is near, a branch is made for that release. This branch is then stabilized/tested and finally a release is made. After the release, the branch is merged back into the trunk, while keeping the release branch alive for bug-fixing. Is a bug-fix applied, then it is merged into the trunk ( if the development on the trunk hasn't eclipsed the bug in other means). New features are added to the trunk and don't affect the release branch.
When a new release time nears, a new release branch is created a.s.o.
"Branch by feature": The trunk is always the "production" trunk (the code that is live). Bugfixes are commited directly to the trunk. Features for the next release are developed in feature branches.Bugfixes are merged from time-to-time into the feature branches. When release time comes, the features branches are merged into the trunk and the cycle of life continues.
Now the way I see it the big practical difference between these two strategies is that "by release" allows you to maintane different production versions of you software ( when client A has version 1 and client B version 1.5, client is the paying customer in this case). In contrast using the "by feature" strategy you can only support the current production version ( all clients are using latest version).
Since in a typical web application all clients are using the same "latest" version (since they all access the same server), I would assume that the "by feature" approach is the most commonly used. It removes the need to merge "across the hierarchy", say when a bugfix has to be applied to all 3 release versions.
So my current status is that I should go with "branch by feature". If it matters, my team is not very skilled.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您在任何时间只有一个版本，并且您在单个功能分支中进行所有开发，那么这些方法实际上是相同的。
如果逐个功能对您来说意味着同时拥有多个分支，那么我会像避免瘟疫一样避免它。更多的分支意味着更多的合并，这本身就是一种痛苦，也是更多的集成地狱。对单个代码线进行持续集成要好得多。
如果您的部署过程比分支、测试、上线更复杂，那么逐个发布的一个优点是您可以在不同的阶段同时运行多个发布分支：一个上线并根据需要进行错误修复，并且另一种正在稳定、测试、验收等，同时主干上的开发仍在继续。另一方面，如果您有一个实时主干，一旦您合并一个功能分支以使其上线，您就失去了对当前实时系统进行错误修复的能力。功能分支合并成为一个不归路。
If you only have one release live at any time, and you do all development in a single feature branch, then these approaches are effectively the same.
If branch-by-feature to you means having a several branches on the go at once, i'd avoid it like the plague. More branches means more merging, which is a pain in itself, and more integration hell. It's far better to do continuous integration to a single codeline.
If your deployment process is any more involved than branch, test, go live, then an advantage of branch-by-release is that you can have multiple release branches going at once, in different phases: one live and being bugfixed as necessary, and another one being stabilised, tested, going through acceptance, etc, while development continues on the trunk. If you have a live trunk, on the other hand, once you merge a feature branch in with a view to taking it live, you've lost your ability to do bugfixes to the current live system. The feature branch merge becomes a point of no return.
您正在开发什么类型的软件？收缩包装？开源项目？如果是这样，那么请采用“通过发布分支”或“不稳定主干”方法。特别是如果您的发布周期每隔六个月到一年一次。
但是，如果您维护的基于 Web 的项目的更改频率较短，例如每隔几周或更短一次，那么请采用“按功能分支”或“稳定主干”方法。这种方法的问题是集成多个功能更改，这些更改具有全面的更改，使合并过程变得不那么有趣。这真的变得很困难。
但这两者都很好用，但如果你两者都需要怎么办？也就是说，您有一个项目，每隔几周部署一次，并进行重大功能更改，但您发现有许多错误修复，您无法等待这些功能更改准备就绪。主干是采用“按功能分支”方法的发布分支。如果您可以获得两个版本和功能各自的分支怎么办？
查看 CollabNet 的 Bob Archer 的这篇博客文章。他的敏捷发布策略为您提供了两者的最佳选择。我用过这个。它非常灵活。即使鲍勃没有在他的图表中显示它，您也可以同时运行多个发布分支。这意味着您可以拥有一个已准备好部署到生产环境的发布分支，以及另一个正在准备进行最终 QA 检查的发布分支。但需要考虑两件事：
首先，您的开发人员在合并方面的能力如何？即使是一个小团队，你也无法独自实施敏捷发布策略方法。每个人都必须尽自己的一份力量，他们必须真正了解合并以及他们用来进行合并的工具。
其次，您需要很好地掌握已经准备好的和即将发生的变化。发布管理是让这项工作像时钟一样工作的关键。每个功能准备就绪后都需要分配给发布分支并合并到其中。
无论您选择哪种方法，都取决于您正在开发的内容以及您为该开发发布的更改的频率。
What kind of software are you developing? Shrink wrap? Open Source Project? If so, then go with the "branch by release" or "unstable trunk" approach. Especially if your release cycles are every six months to a year apart.
But if your maintaining a web-based project that has changes going out on shorter frequencies, like once every few weeks or less, then go with the "branch by feature" or "stable trunk" approach. The problem with this approach is integrating multiple feature changes that have sweeping changes make the merge process less than fun. It just really gets difficult.
But both of those work well, but what if you need both? That is, you have a project that deploys says once every couple of weeks with big feature changes, but you find that you have a number of bug fixes that you cannot wait for those feature changes to be ready. Trunk is your release branch with the "branch by feature" approach. What if you could get both releases and features their own branch?
Check out this blog entry by CollabNet's Bob Archer. His Agile Release strategy gives you best of both. I've used this. It's extremely flexible. Even though Bob doesn't show it in his diagram, you can have multiple release branches going at the same time. This means you could have one release branch that is ready for rollout to production, and another that is being prepared for final QA checks. But two things to consider:
First, how good are your developers at merging? You cannot do the the agile release strategy approach by yourself, even if it is a small team. Everyone has to do their part and they really have to understand merging and the tools they are using to do the merge.
Secondly, you are going to need a good grasp on changes that ready and those that are about to be. Release management is key to making this work like clock work. Each feature when ready will need to get assigned to a release branch and merged to it.
Whatever approach you choose, it comes down to what you are developing and the frequency of changes you are releasing for that development.
冒着让您进一步困惑的风险：您可以拥有发布分支并在功能分支上进行所有更改。这些东西并不是相互排斥的。
话虽这么说，听起来您不需要并行版本系列，并且您希望经常部署，甚至可能 连续。所以你会希望有一个可以随时释放的“稳定的主干”。功能分支有助于保持主干的稳定，因为只有当更改完成并证明其效果时，您才能合并回主干。
所以我想说你的选择很合适。
At the risk of confusing you further: you can have release branches and make all changes on feature branches. These things are not mutually exclusive.
That being said, it sounds like you don't need parallel release families and you want to deploy often, perhaps even continuously. So you would want to have a "stable trunk" that you can release at any time. Feature branches help to keep the trunk stable, because you only merge back to the trunk when the changes are done and have proven themselves.
So I'd say that your choice is a good fit.
这些选择并不相互排斥 - 两者都使用。它们解决不同的问题：
“按版本分支” - 使用版本分支来确保您可以当下一个版本正在开发时，返回到用于生成当前实时版本（或以前发布的版本）的源。例如，这是为了对发布版本进行更改，以修复当前开发主干的错误或回补功能。
“按功能分支” - 用于始终保持稳定的开发主干，这对于多个开发人员和实验性“可能”功能特别有用。
我会同时使用这两种方法，但如果其中一种方法解决的问题不适用于您，或者您对该问题有不同的解决方案，您可以放弃其中一种方法。
我强烈建议使用现代 DVCS，例如 git 或 Mercurial。它们适合并行开发，因此它们存储更改的方式与旧系统不同，这使得合并更加明智。
These choices are not mutually exclusive - use both. They solve different problems:
"Branch by release" - release branch is used to ensure you can back to the source used to produce the current live version (or previous released versions) while the next version is in development. E.g. This is in order to make changes to the release version for bug fixes or backpatch features from the current development trunk.
"Branch by feature" - used to keep a stable development trunk at all times, which is particularly useful for multiple developers and for experimental "maybe" features.
I would use both, but you can forego one of the approaches if the problem it solves doesn't apply to you or if you have a different solution that problem.
I strongly recommend using a modern DVCS like git or Mercurial. They are geared at parallel development, so they store changes differently than older systems, which makes merging much saner.
我倾向于在我的项目中使用 Git，但我倾向于遵循的流程是这样的（并且也应该适用于 Subversion）：
staging分支中，并将其部署到登台服务器（您确实有其中之一，对吧？）product_release_22或product_release_new_feature_x之类的内容，然后将该标记部署到生产服务器。标签从不、永远更新 - 一旦部署某些内容，它就会保持这种状态，直到构建、测试和标记更多更改 - 然后部署新标签。通过确保部署的是标签而不是分支，我可以防止自己（或其他人）做类似“我只需提交这一快速更改并更新服务器未经测试”。
到目前为止，它对我来说效果很好。
I tend to use Git for my projects, but the process I tend to follow goes like this (and should work for Subversion as well):
stagingbranch, and deploy it to the staging server (you do have one of those, right?)production_release_22orproduction_release_new_feature_x, and then deploy that tag to the production server.Tags are never, ever updated - once something gets deployed, it stays that way until more changes are built, tested, and tagged - and then the new tag is deployed. By making sure that it's tags getting deployed and not branches, I keep myself (or others) from doing things like "I'll just commit this one quick change and update the server without testing it".
It's worked pretty well for me so far.