Git 工作流程

Git 工作流程

运行环境

本地开发环境

自己电脑上的工作环境

CI环境

持续集成运行环境

测试环境

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

预发环境

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

生产环境

正式发布后的运行环境

各分支的职责

开发分支

对应测试环境

基于 master 分支来建立开发分支(命名规范待定)

线上的Bug修改，新功能开发，都在开发分支上进行。

每个开发分支的程序，都在测试环境单独运行，供测试人员进行测试。

master分支

对应测试环境，不再对应预发环境

所有开发分支的修改，在测试环境测试通过后，都必须首先合并到 master 上。

master 分支的程序，也要在测试环境单独运行，供测试人员进行回归测试。

release分支

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

分支工作流程

流程图

新功能开发

在 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，重新回到开发分支修改，测试