首页 文章

合并/分支战略

提问于
浏览 次
8

我们正在努力实现最新Visual Studio TFS Branching and Merging Guide中ALM Rangers所描述的"Basic Dual Branch Plan" . 从指导：

具有MAIN，DEV和RELEASE分支的基本分支计划支持您的下一个版本的并发开发，用于测试的稳定MAIN分支和用于任何船舶阻止错误修复的RELEASE分支 . 通过从MAIN创建其他开发分支来支持多个开发区域 . 这些是彼此的对等和MAIN的孩子 . 通过为每个产品版本创建发布分支来支持其他版本 . 每个发布分支都是MAIN的子代，彼此之间是对等的（例如，版本2.0分支是对等版本3.0，并且都是MAIN的子代） . 如果一次只支持 生产环境 中的单个版本，您可以考虑单个版本分支，并直接在此分支上修复错误 . 创建RELEASE分支后，MAIN和开发分支机构可以开始接受为下一个产品发布批准的更改 .

我们尚未决定是否要使用单个Release分支（和标签发布），或者每个版本创建一个新的发布分支 . 但是，有一些问题适用于任何一种方式，这些问题似乎没有得到指导的解决 .

我的主要问题是：在什么时候我们应该创建一个RELEASE分支（或者将测试代码移动到单个RELEASE分支，如果这是我们的方式）？

  • 我的第一反应是只在准备好发布时才创建它，但是你遇到了为开发和测试下一个sprint创建死锁的问题's work; you cannot check these changes into MAIN until the RELEASE branch has been created (if you do, it'更难以分离出你只想去RELEASE的更改） .

  • 第二个想法是在sprint开始时创建RELEASE分支，并且当更改通过MAIN中的测试时，将它们合并到当前的RELEASE分支 . 一旦我们到达sprint的末尾，我们就可以锁定RELEASE分支，并为下一个sprint创建一个新的分支 . 这听起来像它可以工作，但我看不到任何地方的讨论，所以我只是想看看人们在做什么 .

tfs merge branch tfs2012 branching-and-merging

2 回答

  • 5

    我会给出与Adarsh Shah相同的建议，因为在大多数情况下，2个分支（MAIN，RELEASE）就足够了，并且使用feature branches用于你不想立即提交到MAIN的东西，因为它需要一段时间才能完全准备好测试 . 通过RELEASE，我指的是每个实际版本的分支 .

    请记住，从理论上讲，MAIN应该随时处于释放就绪状态 . 这意味着使用特征分支也可以进行大量的小改动，只要该功能不被认为是准备好的，就不会将东西合并到MAIN中 . 现在，您应该尝试这一点，看看哪种方式最适合您的环境 . 如果您发现将MAIN保持在发布就绪状态太难了，请务必创建一个单独的DEV分支来提交日常工作 . 然而，根据我的经验，通过一些良好的指导，自动和手动测试，您可以快速进入MAIN可以被认为非常稳定的流程 . 我曾经在我们有一个非常不稳定的DEV分支和一个稳定的MAIN分支的环境中工作，以及我们没有DEV分支的环境 . 有时需要DEV分支，有时它会使它们保持同步，因为DEV和MAIN都相当稳定，基本上只是彼此的副本 .

    现在，何时应该创建发布分支 . 这取决于您正在进行的开发类型 . 对于小型桌面项目或具有相当稳定的发布周期的网站（例如，每个sprint发布一个版本），我发现在sprint结束时创建一个发布分支最容易，之后只能将其推送到 生产环境 sprint .

    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推入 生产环境 环境 . 我发现这种方法很有效 . 你基本上有一个完整的sprint来解决发布分支中的最后一个问题 .

    当然，如果 生产环境 中出现严重的关键错误，则此错误优先于其他所有错误 . 然后可以创建正在 生产环境 的现有R分支的RXa，RXb，...分支，实现热修复并将该热修复推送到 生产环境 中 . 然后你可以考虑是否需要它将热修复中的更改合并到MAIN分支中 . 不要在MAIN分支上创建一个热修复并将其合并，但是你会发现它很快变得太复杂，因为在MAIN上很多周围的代码可能已经改变了 .

    回复于
  • 1

    这是我建议的：

    1）在主分支上进行所有开发，直到代码完成 . 代码完成是开发人员停止处理该sprint的新功能但可以修复回归错误的时间 . 代码完成可以在发布前几天，也可以根据您的冲刺时间长达一周 .

    2）此时从MAIN创建一个新的RELEASE分支 . 将分支部署到QA / Staging环境以进行冒烟测试 . 在此之后，QA团队将使用RELEASE分支对发布进行测试 .

    3）开发人员可以在此时开始处理下一个sprint的新功能，并开始检入MAIN分支的更改 . 测试期间发现的任何回归问题将首先在RELEASE分支中修复，然后合并回MAIN .

    4）然后将对RELEASE分支中的代码的任何更改推送到QA / Staging以进行进一步测试 .

    5）发布完成后，在 生产环境 中发现的任何错误都将在RELEASE分支中修复并热修复到Prod并合并回MAIN .

    排名第一，为时已晚，没有 . 2 IMO会过早 .

    我建议为每个RELEASE创建一个新的分支，然后定期删除旧的RELEASE分支而不是使用标签 .

    此外，我更喜欢只有2个分支MAIN（也是DEV）和RELEASE，除了任何分支开发人员需要任何特定的功能/框架更改等 . 在根文件夹下我通常创建MAIN，RELEASES（所有发布分支）和BRANCHES（所有特定于功能/框架的分支更改等但这些仅在特殊情况下创建并不总是如此）

    回复于

相关问题