在Web应用程序的开发/维护期间应该使用什么分支策略？ [英] What branching strategy should I use during the development/maintenance of a web application?

问题描述

我正在尝试确定Web应用程序项目的最佳分支策略。这是我到目前为止提出的内容，我将不胜感激任何评论和经验。

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.

现在，我认为这两种策略之间的最大实际差异是按发行版允许您维护软件的不同生产版本（当客户端A具有版本1和客户B版本1.5，在这种情况下，客户是付费客户）。相反，使用按功能策略则只能支持当前的生产版本（所有客户端都使用最新版本）。

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).

由于在典型的 Web应用程序中，所有客户端都使用相同的最新版本（因为它们都访问同一服务器），因此假定按功能方法是最常用的方法。这样一来，无需跨层次结构进行合并，例如，必须将错误修复程序应用于所有3个发行版本。

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.

推荐答案

如果您随时都只能发布一个发行版，并且在单个功能分支中进行所有开发，那么这些方法实际上是相同的。

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.

如果您的部署过程比分支，测试，上线更复杂，那么by-by的优势-release是指您可以在不同的阶段同时运行多个发布分支：一个分支处于活动状态并根据需要进行了错误修复，而另一个分支正在稳定，测试，通过验收等，而开发仍在继续进行。另一方面，如果您有活动中继，则一旦合并功能分支以使其生效，您就失去了对当前活动系统进行错误修复的能力。功能分支合并将成为无收益的点。

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应用程序的开发/维护期间应该使用什么分支策略？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！