适合自己团队的 Git 工作流程

运行环境

本地开发环境

自己电脑上的工作环境

CI环境

持续集成运行环境

测试环境

提交给测试人员时，程序的运行环境

预发环境

与生产环境一致，但是不对外开放，供测试人员基于生产环境的数据，做最后一次测试

生产环境

正式发布后的运行环境

各分支的职责

开发分支

• 对应测试环境
• 基于 master 分支来建立开发分支(命名规范待定)
• 线上的Bug修改，新功能开发，都在开发分支上进行。
• 每个开发分支的程序，都在测试环境单独运行，供测试人员进行测试。

master分支

• 对应测试环境
• 所有开发分支的修改，在测试环境测试通过后，都必须首先合并到 master 上。
• master 分支的程序，也要在测试环境单独运行，供测试人员进行回归测试。

release分支

• 对应预发环境，和生产环境

分支工作流程

流程图

Gitlab 工作流程 v1.0

Gitlab 分支工作流程

新功能开发

1. 在 Gitlab 建立 Milestone 和 Issue。
2. 从 master 建立开发分支，进行新功能开发。
3. 开发完成后，进行测试。
4. 测试完成后，给需求方做评审。
5. 评审完成，提交 Merge Request 向 master 合并。
6. Review 通过后，执行 Merge Request。

线上Bug修复、紧急上线的开发

1. 建立 Issue
2. 从 master 建立开发分支，进行Bug修改。
3. 开发完成后，进行测试。
4. 测试完成，提交 Merge Request 向 master 合并。
5. Review 通过后，执行 Merge Request。

测试环境的测试

• 开发分支先把当前分支部署到测试环境做测试。
• 之后，所有开发分支的修改都必须先合并到 master 分支，并提交测试，最好在合并到 master 后做一次回归测试。
• master 测试没通过时，继续回到开发分支修改Bug，然后测试开发分支，然后合并到 master 测试

预发环境的测试

• 对于新功能，master 合并到 release ，部署到预发环境继续测试
• 对于Bug和紧急功能，从 master 上 cherry pick 相关 commit 到 release，部署到预发环境继续测试
• 预发没有测试通过时，继续回到开发分支修改Bug，从测试环境重新测试

上线发布

• release 在预发环境测试通过后，直接发布上线
• 上线后的Bug，重新回到开发分支修改，测试