前言

如果你的项目是多人多功能同时开发；如果你的项目是走敏捷迭代，需要随时发布的能力；如果你遇到测试环境不够用、代码经常被覆盖；如果需要代码 merge 后自动实现 CI/CD；亦或是现在的分支管理方案非常复杂，需要依赖人为约定或者工具；那么本文提出的新型分支管理方案可能非常适合，欢迎大家一起探讨更适用的解决方案。

常见分支管理方案

这部分将通过对Git Flow、GitHub Flow、GitLab Flow三种流行的工作流程模型进行分析，总结各模型的优缺点与适用场景。

Git Flow

流程图

分支及功能

• 主干 master: 存放线上版本的代码
• 开发 develop: 开发完成的功能分支的集合，等待发布
• 功能 feature: 开发分支从 develop 创建，完成后完成后经过 code review 和测试，合回 develop
• 发布 release: 发布分支从 develop 创建，发布时做辅助用，发布完成后合入 master 和 develop
• 修复 hotfix: 修复分支从 master 创建，修复线上问题时做辅助用，修复完成后合入 master 和 develop

优缺点分析

优点:

• 功能分支独立，互不干扰，可以独立开发、测试
• 当 Feature 分支较长的时候，可以避免提前进 Release
• 具备多个版本发布的能力

缺点：

• 多人多功能开发需要发测试/预发环境验证时，环境不够用、代码经常被覆盖
• 非常依赖团队定期发布的习惯，不适合敏捷迭代
• 可以说是流程里最复杂的，学习成本稍微高一点
• 如果发布较多的时候，处理 PR/MR 就要花很多时间

GitHub Flow

流程图

分支及功能

• 主干 master: 存放线上版本的代码
• 功能 feature: 开发分支从 master 创建，完成后经过 code review 和测试，可以直接发布，再合入 master
• 修复 hotfix: 修复分支从 master 创建，和 feature 同理

优缺点分析

优点：

• 操作简单，可以持续发布

缺点：

• 流程较为简单，不适合多人多功能开发
• 需要开发人员有测试驱动开发的能力，能够跑完本地测试后方才进行PR
• 如果同时要维护多个版本，就很痛苦

GitLab Flow

流程图

分支及功能

• 主干 master: 开发完成的功能分支的集合，等待发布
• 功能 feature: 开发分支从 master 创建，完成后经过 code review 和测试，合回 master
• 发布 production: 预发分支 pre-production 只接收从 master 发起的 mr；发布分支 production 只接受从 pre-production 发起的 mr。保证整体合并顺序是单向的。
• 修复 hotfix: 和 feature 类似，合回 master 之后，再合入所有发布分支中

优缺点分析

优点：

• 方案同时兼顾了“版本发布”、“持续发布”
• 能够对各环境版本有较好的区分，对测试团队支持较好

缺点：

• 为了应付预发和线上环境，除了 master 还有别的辅助分支，环境多的话分支也会变多
• Hotfix 处理变成和 feature 分支类似了，从 master 创建，往回合的时候需要多次 cherry-pick

新型分支管理方案

如上阐述，每个分支管理方案都有一些缺点，可能各自的试用场景不太一样。我们小组的业务是多人多功能迭代，所以之前尝试过 Git Flow，最后因为一些敏捷迭代等问题放弃了。后来我们在多次实践的基础上，沉淀了一种新的 flow，解决了常见的敏捷迭代的一些问题；同时结合 Devops 钩子，可实现各环境对应分支代码 MR 后，自动发布部署；最重要的是：足够简单！！！

流程图

分支及功能

master

• 分支含义：线上逻辑分支
• 准入条件：所有逻辑完成功能验收待上线，从 release 或者 hotfix 分支合入 master，结合 Devops 可实现自动 CI/CD
• MR source：release、hotfix
• MR Target：不限制

develop

• 分支含义：只是用来发测试环境的，仅此而已，千万不要将dev合到开发分支！！！有多环境的时候同理，比如develop对应开发环境，qa对应测试环境
• 准入条件：代码开发完成，需要联调或者测试时，所有的feature即使不同时上线都可以合dev，可能需要解决冲突，但是终究要解决
• MR source：feature
• MR Target：Forbidden
• 发 MR 时机：所有流程测试完后发 MR，项目管理者准入
• 进度同步原则：需及时同步 master 分支

feature-*

• 分支含义：需求功能开发分支，一般必须基于 master 拉取，有依赖的可以基于其他依赖 feature 分支新建。
• 准入条件：分支 committer 自行确认是否合入
• MR source：master，如果当天上线可以是 release
• MR Target：develop、release
• 发 MR 时机：开发完成时发 MR
• 进度同步原则：需及时同步 Master 分支

release-*

• 分支含义：功能分支发预发环境，格式一般为：release-20201230，用以合并当天需要上线的 feature。发布预发环境验收完成后，合入 master 打上线包
• 准入条件：当天需要上线的功能分支
• MR source：feature
• MR Target：master
• 发 MR 时机：代码功能最终确认，需要发预发环境时

hotfix-*

• 分支含义：线上问题紧急修复分支，格式一般为：hotfix-20201230，发布预发环境验收完成后，合入 master 打上线包。如果当天有需要上线的 release 分支，也可以合入 release 一起上线
• 准入条件：分支 committer 自行确认是否合入
• MR source：不限制
• MR Target：master、release
• 发 MR 时机：修复开发完成时发 MR，同时发测试环境，测试完成后合入

优缺点分析

优点：

• 解决多人多功能开发需要发测试环境验证时，测试环境不够用，代码经常被覆盖等问题
• 理论上，代码可以随时发布，非常适合敏捷迭代
• 结合 Devops 钩子，可实现各环境对应分支代码 MR 后，自动 CI/CD
• 足够简单，方便实践和推广

缺点：

• 可能需要多次解决冲突
• 提测的分支和上线的分支不一致

这里说下这两个缺点：

第一个冲突的问题是因为我们在发需求提测和上预发的时候可能都需要解决 feature 之间的冲突，在冲突很少的情况下解决成本也不高。对于协同度很高的项目，为了防止在各环境多次解决冲突的问题，建议从 master 拉一个比如 feature-merge 分支，一次性解决冲突。

第二个问题，可能大家比较关心，因为一般我们认知上测试功能和上线的功能是一致的，现在测试环境不是纯粹的，可能耦合了其他正在测试的功能。我理解在测试过程中功能互相影响的场景是应该要考虑到的，我们之前就有过这样的案例，两个需求有关联，但是到上线时才发现关联部分未开发而导致了上线风险。在测试阶段越早把这部分问题暴露出来反而越好，这样有益于项目的风险把控以及测试的完整性。如果担心代码的纯粹性，流程里还有个预发环境，就是做这个事情的：回归和兜底。

总结

本文阐述了常见的 Git 工作流的使用姿势和优缺点，同时提出了一种新的 Git 分支管理方案，希望对大家有帮助。

最后，硬广一下，我们是字节跳动-商业变现前端团队。商业产品部门作为字节跳动的变现中台，承担了抖音、头条、西瓜、火山等字节全线产品矩阵的收入变现职责。团队详细介绍：商业变现前端团队 。我们岗位包含北/上/杭/北美多地base，建议直接发送简历至邮箱，会有专人传送简历至目标入职base～ 简历直达邮箱：weitianyao@bytedance.com