代码版本管理的流程

一、主要目标

1. 保证环境的独立性：开发环境、测试环境、生产环境

1. 避免过多分支切换带来的开发成本

我们的Git-flow就是为了达到上述两者的平衡

二、具体做法

（一）每个项目常备三个分支

（1）dev、origin/dev

开发分支，包含了所有开发环境下的代码。推送dev分支会触发开发环境的自动构建部署。

（2）staging、origin/staging

测试分支，包含了所有测试环境下的代码，日常开发下不要往 staging 合并，更不要往 origin/staging 推送。

staging 分支合并需要经过 merge request，进入需求开发以后，就可以发起 merge request 了；提测前会通过合并。

暂时不考虑保护 staging 分支。

（3）master、origin/master

生产分支，包含了所有生产环境下的代码。

只有通过测试的 origin/staging 分支，才可以合并到 master 分支。

master受到保护。

（二）分支模型图

（三）使用场景

（1）开发新需求

Shell # 从 staging 分支上切换新的分支进行开发，此时可以发起 Merge request 到 staging git fetch git checkout -b feature/[功能名称] origin/staging # 开发过程中注意同步 origin/staging git fetch git merge origin/staging # 开发结束以后，将代码合并到 dev # 并推送到远程仓库，它会自动触发开发环境下的构建流程，从而部署开发环境 git checkout dev git merge feature/[功能名称] git push # 在开始开发时发起的 Merge request，由相关人员 review，并在提测前通过 # 将代码合并到 staging 分支，通知测试可以提测，测试环境由测试人员构建部署

（2）提交测试

发起 Merge request 到 staging，MR 通过以后，通知测试进行提测

（3）测试Bug修复

直接在 feature/[功能名称] 分支上修复，修复后合并到 staging 分支上，以供测试；测试验证通过，将 origin/staging 合并入 dev 分支（也可以将自己已经修复完毕bug的 feature/[功能名称] 合并到 dev 分支）；

（4）正式环境部署

合并 origin/staging 到 master，并推送到 origin/master

（5）正式环境bug修复

从 origin/master 切出 hotfix/[bug] 分支，修复后，再发起 merge request 到 master 分支；同时，还要合并到 staging 分支。

三、如何减少合并冲突的次数以及冲突范围

（一）日常开发中，要注意及时合并 staging，在开发新的代码前要合并远程仓库的代码

Bash # 当前分支为特性分支，在开发新的代码前，注意合并远程 staging 中的代码 git fetch git merge origin/staging

（二）一旦产生冲突，要找到另一方冲突人，一起协商解决冲突

不要私自覆盖他人代码！

不要私自覆盖他人代码！

不要私自覆盖他人代码！

（三）分支应与特性对应，不是与个人对应，不要一直用同一个分支开发不同功能的代码

分支不值钱，随便开。