问题描述
我们正在尝试实施ALM Rangers在最新《 Visual Studio TFS分支和合并指南》中描述的基本双分支计划".一个>.从指导中:
We are trying to implement the "Basic Dual Branch Plan" as described by the ALM Rangers in the latest Visual Studio TFS Branching and Merging Guide. From the guidance:
通过为每个产品发行版创建发行分支来支持其他发行版.每个发行分支都是MAIN的子级，并且彼此对等(例如，发行版2.0分支与3.0版是对等的，并且两者都是MAIN的子级).如果一次仅支持生产中的一个发行版，则可以考虑一个发行版分支，然后直接在此分支上进行错误修复.一旦创建了RELEASE分支，MAIN和开发分支就可以开始进行批准用于下一个产品版本的更改.
Additional releases are supported by creating release branches for each product release. Each release branch is a child of MAIN and a peer to each other (e.g. release 2.0 branch is peer to release 3.0 and both are children of MAIN). If supporting only a single release in production at a time, you may consider a single release branch, and make bug fixes directly on this branch. Once the RELEASE branch is created MAIN and the development branches can start taking changes approved for the next product release.
我们不确定要使用单个Release分支(和标签releases)，还是要为每个发行版创建一个新的release分支.但是，有些问题适用于这两种方式，但该指南似乎并未解决.
We are undecided as to whether we want to use a single Release branch (and label releases), or create a new release branch per release. However, there are some questions that apply either way, that don't seem to be addressed by the guidance.
我的主要问题是:在什么时候我们应该创建一个RELEASE分支(或者如果这样的话，应该将经过测试的代码移到单个RELEASE分支上)?
My main question is: At what point in time should we create a RELEASE branch (or move tested code to the single RELEASE branch if that's the way we go)?
- 我的第一个反应是仅在准备好发布时才创建它，但是接下来的问题是为开发和测试下一个sprint的工作创建死锁；在创建RELEASE分支之前，您无法将这些更改签入MAIN(如果您这样做，则将您只想转到RELEASE的更改分离出来将更加困难).
- 第二个想法是在sprint的开头创建RELEASE分支，并且当更改通过MAIN中的测试时，将其合并到当前的RELEASE分支.一旦到达冲刺的末尾，就可以锁定该RELEASE分支，并为下一个冲刺创建一个新的分支.这听起来像可行，但是我在任何地方都没有讨论它，所以我只想看看人们在做什么.
推荐答案
我会提供与 Adarsh Shah 相同的建议在大多数情况下，这2个分支(MAIN，RELEASE)就足够了，并使用功能分支进行您不想立即提交到MAIN中的事情，因为需要花费一段时间才能完全准备好进行测试. 发布"是指每个实际发行版的一个分支.
I would give the same advice as Adarsh Shah in that 2 branches (MAIN, RELEASE) are sufficient in most cases, and using feature branches for things that you don't want to commit into MAIN immediately because it would take a while to be fully ready for testing. And by RELEASE I mean a branch per actual release.
请记住，从理论上讲，MAIN应该随时处于可发布状态.这意味着也可以使用功能分支进行许多小的更改，并且只要不认为该功能已经就绪，就不会将其合并到MAIN中.现在，这是您应该尝试的东西，看看哪种方法最适合您的环境.如果您发现很难将MAIN保持为发布就绪状态，则务必创建一个单独的DEV分支来提交日常工作.但是，根据我的经验，有了一些好的指导方针，自动和手动测试，您很快就会进入可以认为MAIN非常稳定的流程.我曾在一个环境中工作，该环境中我们有一个高度不稳定的DEV分支和一个稳定的MAIN分支，以及没有DEV分支的环境.有时需要DEV分支，有时使它们保持同步成为负担，因为DEV和MAIN都相当稳定，并且基本上只是彼此的副本.
Keep in mind though that, in theory, MAIN should in a release-ready state at any moment. This means using feature branches for a lot of small changes too and not merging things into MAIN as long as the feature is not considered ready. Now, this is something that you should experiment with and see what works best in your environment. If you find that it is too hard to keep MAIN into a release-ready state, by all means, create a separate DEV branch to commit the daily work. In my experience however, with some good guidelines, automated and manual testing you quickly can get into a flow where MAIN can be considered quite stable. I've worked in environments where we had a DEV branch which was highly unstable and a stable MAIN branch, and environments where we didn't have a DEV branch. Sometimes the DEV branch was needed, sometimes it became a burden to keep them in sync as both DEV and MAIN were fairly stable and essentially just a copy of each other.
现在，何时创建发布分支.这取决于您正在进行的开发类型.对于小型桌面项目或网站，其发布周期相当稳定(例如，每个sprint有一个发布)，我发现在sprint的 end 处创建一个发布分支，并仅推送它是最简单的在之后产生冲刺.
Now, when should you create the release branch. It depends on the type of development you are doing. For small desktop projects or websites which have a fairly steady release cycle (a single release per sprint, for example) I find it easiest to create a release branch at the end of a sprint, and only pushing it to production the sprint after.
S1 - - S2 - - S3 - - S4 // Each sprint
\ R1 - \ R2 - \ R3 // Release branch created at the end of a sprint
\ P1 - \ P2 // Pushed to production at the start of the next sprint
因此，在S1的结尾，我从MAIN创建了发布分支R1，但尚未将其发布到生产环境中.在S2期间，这两个新功能都在MAIN上实现，而关键错误已在R1上修复.如果批准了对R1的修复程序，则也可以将其合并回MAIN(如果需要).在S2的末尾，将创建一个新的R2，并将R1投入生产.我发现这种方法可以很好地工作.您基本上有完整的冲刺来解决发行分支中的最后一个问题.
So, at the end of S1 I create the release branch R1 from MAIN but it's not pushed to production just yet. During S2 both new features are implemented on MAIN and critical bugs are fixed on R1. If a fix on R1 is approved, it gets merged back into MAIN too, if it's required. At the end of S2, a new R2 is created, and R1 is pushed into production. I have found this approach to work quite well. You basically have a full sprint to work out the last issues in a release branch.
当然，如果在生产中出现严重的严重错误，则此错误的优先级高于所有其他错误.然后可以为生产中的现有R分支创建RXa，RXb，...分支，实施该修补程序并将该修补程序推入生产环境.然后，您可以考虑是否需要将更改从热修复程序合并到您的MAIN分支中.不过，不要在MAIN分支上创建修补程序并将其合并下来，您会发现它很快变得太复杂了，因为在MAIN上许多周围的代码可能已经更改了.
Of course, if a serious critical bug appears on production this bug gets priority above all else. An RXa, RXb, ... branch can then be created of the existing R-branch that's in production, implement the hot-fix and push that hot-fix into production. You can then consider whether it's needed to merge the changes from the hot-fix into your MAIN branch. Don't create a hot-fix on the MAIN branch and merge it down though, you'll find that it quickly becomes too complex because on MAIN a lot of the surrounding code might have already changed.
这篇关于合并/分支策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！