一种 gitlab 版本管理策略

背景

• 目前负责小组内源码的版本管理，将目前的我们的源码管理策略做一番梳理和分享，以期共同进步。

流程

1. 先建立主分支master

2. Owner基于master建立开发分支xxx-dev-v1，xxx-release-v1,分别是第一期开发版本,第一期发布版本。

3. xxx-dev-v1供开发人员拉取并开发，功能点开发完成且单元测试通过后，将开发代码提交到xxx-dev-v1上。

4. 测试人员测试xxx-dev-v1的代码，测试通过后，由本人将xxx-dev-v1的代码合并到xxx-release-v1，待发布。发布前若测试人员发现bug,则重复3、4步。

5. 发布时，由Owner将xxx-release-v1合并到master分支，合并后master分支打tag，如master> git tag 20171220-v1.0，然后运行自动发布脚本进行发布。

6. 项目是迭代开发，第一期完成后该进行第二期开发，命名方式相同，依次类推。

7. 如果在开发V2的过程中，需要紧急修复V1（线上）中的漏洞，则重复3、4、5步，并在最后将master的代码合并到V2上，以保证V2的代码最新；如评估后不紧急，可放在V2中开发。

注意

1. 务必保证master是线上最新版本。

2. 可改进的地方：经过一段时间的策略使用，认为目前的问题在于角色分工上不够明确，具体表现在两个问题：（1）开发人员代码开发并提交dev分支后，应该提起dev到release的合并请求，由Owner审核后通过，而不是Owner发起合并（2）测试人员在测试没有bug后应提起release合并到master的请求，而不是由Owner发起合并。