一种 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 发起合并。