轻量级小团队的分支策略

Question

我们是一个小团队（3人），每3周左右发布一次。我们的服务是由公司的其他面向客户的服务消费的。该项目处于起步阶段，因此我们希望在有机会的同时使分支策略正确 这是我们天真的想法，我们将支持基于主干的开发，并且只有在必要时才会创建功能分支。我们将有另一个名为“CurrentRelease”的分支，它在任何给定时间都包含当前部署的代码。在sprint结束时，在我们命中Code完成后，我们将trunk合并到CurrentRelease进行最后一轮验证和发布。我们将在主干和CurrentRelease分支上运行CI作业 正如我们现在看到的那样，在我们从trunk到CurrentRelease合并的时间和我们实际发布的那一天之间存在一个小的转换窗口，其中CurrentRelease分支并不完全反映生产中当前运行的代码。现在，如果我们在这段时间遇到紧急错误，我们就没有现成的分支，我们可以去检查修复程序，运行CI并发布。什么可能是一个很好的解决方案呢？
  我们实际上应该有像CurrentPreRelease和CurrentRelease这样的2个CurrentRelease分支吗？最初，CurrentRelease和CurrentPreRelease都包含当前生产部署的代码，后续版本的合并顺序为trunk -->(on the day of Code freeze) --> CurrentPreRelease --> (on the day of production deployment) CurrentRelease。

Answer 1

  

这可能是一个很好的解决方案吗？

不要使用SVN（看起来你是SVN-boys，至少是用过的术语），在DVCS中分支合并要容易得多

即使使用SVN - 来自CurrentRelease@HEAD-1的分支（在trunk的mergeset之前）修订，提交修复，合并回CurrentRelease，删除hotfix-branch（不是强制性的，仅用于完美树）。解决方案的变体是使用可重写（非规范方式）标签CurrentRelease以及CurrentRelease分支 - 部署版本始终存在于CurrentRelease标记中，您可以从中分支修补程序并将其复制到部署的CurrentRelease @ HEAD（它可以|必须成为部署程序的一部分）