代码质量过程管理流程图（多环境）

pull 拉取

bug

SIT

dev

checkout branch

开发自测和提测冒烟通过

提测不通过时的clone

④

项目clone

1、项目开发启动时，开发人员 clone 项目，切换分支到sit，并分别创建远端和本地源分支 dev . （hint：该步骤建议有，能更灵活可控）；2、进行分支版本开发，从本地源分支 dev，创建（checkout）对应的版本分支，如 dev-1.0.0.0（如①）；3、当版本分支代码需要提交时，则向 SIT 分支进行push；拉取代码则 pull（如②）；4、当版本分支开发完成，开发人员在 SIT 联调和开发自测通过后，发起提测；测试人员在 SIT 进行冒烟测试5、当在 SIT 冒烟测试不通过，则测试人员拒绝 merge 该分支代码到 UAT，此时测试人员将在远端仓库的 SIT 创建一临时的分支，命名为 qa-bug；开发人员则 clone qa-bug 分支进行问题修复（如③）；6、当存在 qa-bug 分支，所有project 的对应分支代码将部署到犀牛环境，在犀牛环境进行冒烟测试，若不通过，则反复；7、当测试人员冒烟通过，则开发人员将 qa-bug 分支代码 merge 到 SIT，最终测试人员将 SIT 代码和 qa-bug 分支代码（如果有），merge 到 UAT（如④），开展系统测试8、完成系统测试，并产品/运营验收通过后，则测试人员封版，此时 uat 分支代码 merge 到 master 分支，准备投产，并标识 tag（如⑤）。其中 tag 格式形如 v1.0.0.0 至于生产环境的救火发布，操作见图提测，须正式邮件发出；提测不通过，将邮件反馈给相关 owner，且只接受 bug 分支的 merge；代码同步完成并冒烟通过后，重新回到 SIT-UAT 的工作模式；封版，须正式邮件发出

紧急发布的 merge

⑤

所有依赖的工程将部署到新的环境——犀牛环境

clone

③

如果有β环境等，可以再利用 master 分支进行分发部署

①

UAT

main DEV Branch

分支创建/切换 checkout

研发代码质量过程管理（提测与打回修复版）

②

封版与发布

push

dev-1.0.0.0

Emergency branch

merge

对应的 Git 命令示例如下：// clone 工程库到本地，但只会在本地默认创建一个master分支$ git clone http://.....git// 查看所有远端分支信息（本地用 --list）$ git branch -r// 将 clone 到本地的工程库切换到 sit 分支$ git checkout sit // 创建本地的版本分支，如 dev、dev-1.0.0.0$ git branch dev$ git branch dev-1.0.0.0// 切换到创建后的版本分支$ git checkout dev-1.0.0.0// 也可以用创建新分支并立即切换的命令： git checkout -b dev-1.0.0.0// 在coding 完成后，提交所有的（字符 ' . ' 点号表示所有）变更内容到 git 本地库的暂存区$ git add . // 将暂存区的内容提交到本地库，并附上提交内容的标题$ git commit -m '修复订单下单不成功的bug' // 将 dev-1.0.0.0 变动后的代码提交到远端 sit 分支$ git push origin dev-1.0.0.0:sit// 如果拉取代码，比如拉取远端 sit 分支代码到本地的版本分支$ git pull origin sit:dev-1.0.0.0

Master

紧急发布

临时的qa-bug

犀牛环境是另一套与 UAT同步的环境

dev-1.5.0.0.....................dev-1.8.1.0............

系统测试