适合自己团队的 Git 工作流程
运行环境
本地开发环境
自己电脑上的工作环境
CI环境
持续集成运行环境
测试环境
提交给测试人员时，程序的运行环境
预发环境
与生产环境一致，但是不对外开放，供测试人员基于生产环境的数据，做最后一次测试
生产环境
正式发布后的运行环境
各分支的职责
开发分支
- 对应测试环境
- 基于 master 分支来建立开发分支(命名规范待定)
- 线上的Bug修改，新功能开发，都在开发分支上进行。
- 每个开发分支的程序，都在测试环境单独运行，供测试人员进行测试。
master分支
- 对应测试环境
- 所有开发分支的修改，在测试环境测试通过后，都必须首先合并到 master 上。
- master 分支的程序，也要在测试环境单独运行，供测试人员进行回归测试。
release分支
- 对应预发环境，和生产环境
分支工作流程
流程图
Gitlab 工作流程 v1.0
Gitlab 分支工作流程
新功能开发
- 在 Gitlab 建立 Milestone 和 Issue。
- 从 master 建立开发分支，进行新功能开发。
- 开发完成后，进行测试。
- 测试完成后，给需求方做评审。
- 评审完成，提交 Merge Request 向 master 合并。
- Review 通过后，执行 Merge Request。
线上Bug修复、紧急上线的开发
- 建立 Issue
- 从 master 建立开发分支，进行Bug修改。
- 开发完成后，进行测试。
- 测试完成，提交 Merge Request 向 master 合并。
- Review 通过后，执行 Merge Request。
测试环境的测试
- 开发分支先把当前分支部署到测试环境做测试。
- 之后，所有开发分支的修改都必须先合并到 master 分支，并提交测试，最好在合并到 master 后做一次回归测试。
- master 测试没通过时，继续回到开发分支修改Bug，然后测试开发分支，然后合并到 master 测试
预发环境的测试
- 对于新功能，master 合并到 release ，部署到预发环境继续测试
- 对于Bug和紧急功能，从 master 上 cherry pick 相关 commit 到 release，部署到预发环境继续测试
- 预发没有测试通过时，继续回到开发分支修改Bug，从测试环境重新测试
上线发布
- release 在预发环境测试通过后，直接发布上线
- 上线后的Bug，重新回到开发分支修改，测试
