代码分支管理策略

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

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

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

master分支：线上分支，一般不允许有任何提交记录，只有tag。上面得版本全部都是经过长时间测试稳定运行的版本tag。
这样子的作用在于：上线发版时，一旦新版本出现问题，会立即回滚到master的上一个稳定版本，将新版本对用户的影响降到最小。
当然，发版时，可以采用灰度发布的策略，小范围的在网关关口导流发布。
如果上线后发现重大问题，可以针对master的版本拉一个分支，修复问题，然后合并回master分支和sit、dev分支。
如果是小问题，往往会针对sit分支进行提单，等到一定的时间统一修复后，再发布上线，合并到master。