项目Git分支管理经验

我们目前的分支管理模式

版本发布：

1. 正式版本和预发环境发布都是基于 release 分支。
2. 线上问题修复是基于当前 release 分支创建新的 hotfix 分支。

开发阶段：

1. 开发分支是基于 develop 分支，迭代开始会将上个版本 release 分支合并到 develop 分支。
2. 个人分支是基于 develop 创建新的个人分支。

提测阶段：

1. 测试环境基于 develop 分支，bug 修改完成后由个人分支合入 develop 分支发布。
2. 预发环境基于 release 分支，bug 修改完成后由个人分支合入 develop 分支再合入 release 分支发布。

比较主流的 Git 分支简介

• master - 主分支 最稳定版本的分支，正式发布的版本都是基于 master；
• develop - 开发分支 更新和变动最频繁的分支，正常开发过程的分支都是基于 develop；
• release - 预发分支 一个版本全部功能开发完成后 ，提交测试和bug修复的分支；
• feature - 功能分支 包含每个开发人员开发的功能点，feature 开发完成后合入 develop；
• hotfix - 正式版本中进行问题修复的分支。

最近项目开发中分支管理遇到的问题

1. 提测阶段 预发发版的问题

   由于 jenkis 脚本限制，预发分支必须是 release-* 开头，中、所以无法直接使用 develop 分支发版，而且后续迭代开发也是基于 develop 分支，所以预发问题回归阶段的 bugfix 同时必须合入 develop 和 release 分支，此时，有两种代码合入方式：

   a：个人分支 dev-xx -> develop -> release

   优点：会带上其他人的commit，并一同发布预发，减少发版次数

   缺点：无法控制他人代码质量或者代码目前是否可以发布预发，可能导致新引入问题和版本问题

   b：个人分支 dev-xx -> develop dev-xx -> release

   优点：当前预发发布版本可控

   缺点：可能增加发版次数

2. 线上问题修复时创建hotfix 分支的问题

   hotfix 可能基于 release 分支或者其他的 hotfix 分支，如果要修复线上问题，则会有以下问题。

   a. 繁琐

   • 分支创建时需要向上一个发版人确定或者在 jenkis 发版记录找；
   • 发版完成后需要将代码合入 develop，否则下个迭代功能上线以后会丢失此次的问题修复代码；

   b. 容易引入问题

   • 如果没有确定正确的线上分支或者确定了错误的分支，则线上会重复出现历史问题；

   • 如果发版完成后代码没有合入 develop，则下一迭代发版后线上也会重复出现历史问；（高频问题点）

3. 并行迭代时的分支管理问题

   真实场景描述：

   工作台 v1.6 迭代开发过程，我们有正常的开发分支 develop，且基于 develop 创建新的个人开发分支 develop-x1、develop-x2等。在 v1.6 结束阶段，由于企业微信迭代优先级问题，全员投入企业微信 v1.0 迭代开发，此时由于 v1.6 未上线，且企业微信迭代和 v1.6 无法同时上线，所以创建新的 develop-wxwork 分支，此时正常的 develop 分支则是停用状态。

   后续企业微信上线阶段，则衍生 release-ww-v1.0 分支完成发版，同时由于预发测试和正式版本差异，预发则基于 release-ww-v1.0 分支创建 release-ww-stage-test 分支，后续线上hotfix 则是基于 release-ww-v1.0。

   在企业微信上线成功后，则是开始 v1.7 迭代开发，且 v1.7 基于 v1.6，此时部分 v1.7 功能合入到 develop ，但在 v1.7 迭代开发中途，由于优先级问题则是开展 V1 和 V2 迭代，且 V1 和 V2 是基于目前线上版本 release-ww-v1.0 开发，并且先于 v1.7 迭代开发，且 V1 、V2 迭代功能无关联并不同时上线，所以，则产生两个新的开发分支 develop-v1 和 develop-v2 进行。

   此时，迭代开发、测试发版、线上问题修复的分支管理已经比较混乱，难以维护。

解决方案思考

1. 上线流程优化 - 正式和测试发布使用 master 分支，预发问题验证则是基于 release，每次迭代分支总是基于 master 创建 develop，线上问题修复基于 master 创建个人 hotfix 分支，验证完毕后合入 master 发布。

   优点：

   a. 线上问题修复总是基于 master ，不存在不明确当前线上版本和 hotfix 代码丢失问题；

   b. hotfix 不需要多次合入其他分支；

   c. 并行开发 develop 分支总是基于 master，不需要确定当前版本，且冲突较少；

   缺点：

   a. 如果发版异常，即时回退比较麻烦，需要在 master 分支撤回异常 commit，再发布；

   b. 需要变更目前的开发上线发版流程和修改 jenkis 脚本；

2. 上线流程优化 - 正式发版和预发发版还是使用目前流程，使用当前迭代 release 分支发版，但是每次线上发版完成后必须将代码合入 master，线上问题修复、后续迭代开发、基于线上版本的并行迭代开发都基于 master 分支创建新分支。

   优点：

   a. 不需要变更当前流程和修改脚本，只需要维护好 master 分支；

   b. 新迭代开发分支创建、hotfix 分支创建方便，都是基于 master；

   c. 线上发版需要回退时迅速，只需要回退到上次的 release 分支即可。

   缺点：

   a. 每次完成线上发版以后，代码必须合入 master；

   b. 如果线上发版后代码忘记合入 master，则下次发版会发生线上代码丢失导致历史问题重现。

   补充：

   可用 jenkis 脚本配置代码上线以后自动合入 master 的功能，这样会很大程度避免线上代码丢失的问题。

3. 测试流程优化 - 目前测试和预发测试阶段，由于同时存在 release 和 develop，个人分支需要同时合入两者。如果提测和预发测试都是基于release 分支修改，此时停用 develop ，那么只需要合入 release 即可，下个迭代 develop 可以再基于 master 和 release 创建。