分支开发，主干发布
工作方式
所有开发或者说主要的开发活动都发生在大大小小的分支上，开发完成后需要合并回主干。每次需要发布时取主干上相应的版本或者标签即可。
- 优点：并发开发支持好
- 待改进：每次上线都要把线上最新的版本和自己的代码进行合并；且合并完需要做快速的验证，只有验证通过后才能上线，此时如果有人又上线了，需要合并代码再次验证。对需要长时间验证或者回归时间长的项目不太适合。
历史分支
主干上每次发布时打的 label/tag 都是相应的已经发布的版本。不需要历史分支。
功能分支
每个功能都要创建相应的功能分支进行开发。
发布分支
按照这个模型来说，所有要发布的代码都需要合并回主干，然后从主干验证通过后，通过主干进行发布。
主干上只保留要上线的代码，代码一旦合并到主干上，要么验证通过发布/上线，要么回退。主干上是用来上线的，不是用来调试、验证合并代码的。这也是为了避免主干长时间被某个功能占据，没有可发布的版本。
一个变通的做法是分支开发、分支发布，分支发布后把分支上的代码同步到主干上，这个时候主干和当前刚刚发布的分支代码是一样的。其它分支则需要从主干合并代码到自己的分支。
如果按照如此说，分支开发主干发布是分支开发分支发布的一个特例。分支开发分支发布的优势是在分支没上线的时候，可以自由安排上线时间，只不过上线越延后，需要从其他分支合并到本分支的代码越多，但是换来的益处是本分支只要不上线就不影响其它分支上线。而分支开发主干上线如果想做到如此则必须是先合并到主干上的代码先上线，要么就回滚，否则会影响后面合并到主干的变更。不过好在无论是哪一种，开发类似功能的都是兄弟团队，都熟悉相关的产品功能，代码实现，所以合并起来，即便是遇到冲突也比较容易解决。
维护分支
只需要维护好主干（线上版本）就好。主干是功能开发、系统上线的基准。所有新分支的创建都要从主干产生。
小结
分支开发主干上线的策略更大程度支持并行开发，但在某些程度上来说稍显复杂，且有一定的代码合并的工作量。
网友评论