代码分支管理策略

代码分支管理策略

一般开发的项目，至少有3个分支：master，dev，test。

dev分支：当前开发的各种新特性新功能都可以不断提交。当要进行正式测试时，从dev打tag拉取一个分支得到test分支。然后测试针对这个分支进行测试。

test分支：测试使用的分支。测试提出来的问题，开发人员修改后提交到dev分支，并合并至test分支，直至全部通过测试。然后上线发布。
上线发布成功后，针对上线成功的版本打tag，合到master，得到master的tag。

master分支：线上分支，一般不允许有任何提交记录，只有tag。 上面得版本全部都是经过长时间测试稳定运行的版本tag。

T；
T+1；

这样子的作用在于：
- 上线发版时，一旦新版本出现问题，会立即回滚到master的上一个稳定版本，将新版本对用户的影响降到最小。
    - 当然，发版时，可以采用灰度发布的策略，小范围的在网关关口导流发布。
- 如果上线后发现重大问题，可以针对master的版本拉一个分支，修复问题，然后合并回master分支和test、dev分支。
- 如果是小问题，往往会针对test分支进行提单，等到一定的时间统一修复后，再发布上线，合并到master。