基于 Git 的开发工作流——主干开发特性总结

在参与开发的过程，得益与平台提供便捷的开发流程，简化很多开发过程操作分支的步骤；也就很好奇，为什么研发平台怎么设计，考虑的点是为什么，便有了这次对主干研发的学习与记录。

当我们是构建软件项目的唯一开发人员时，可以根据个人喜好创建和修改代码。当我们为团队运行的项目贡献代码时，我们需要遵循一套标准化的指导方针并与其他团队成员精确协调。标准指南和协调的工作努力对于每个基于团队的软件开发项目的成功至关重要。

为了满足这一需求，世界各地的工程团队设计了许多开发工作流程。大多数团队使用 Git 进行版本控制和管理他们的软件代码。基于 Git 的两种最流行的开发工作流是基于主干的开发和基于特性的开发。Facebook、谷歌、Netflix 和许多其他科技企业的团队使用这些工作流程。

基于特性的开发

▐ Git Flow

Git Flow 是为了解决多个不同特性之间并行开发需要的一种工作方式。当开始一个特性的开发工作的时候，从主干上拉出一个特性分支，所有的关于该特性的开发工作都发生在这个特性分支上，当完成该特性的工作之后，再把特性分支合并回代码主路径上，并准备发布。

master分支：主开发分支

develop分支：主开发分支

feature分支：功能分支，从develop切出分支，用于功能开发，开发完成后合并到主开发分支

release分支：发布分支，从develop切出分支测试或发布，发布完成后，把release合并到master和develop分支

hotfixex分支：从master切出，修复线上问题，修复后分支合并到master和develop分支

优点：每个分支描述清晰，对于不同问题不同场景，能够很好覆盖开发、发布、bugfix的流程

缺点：分支类型多，增加开发人员理解成本、操作成本（不同分支间合并冲突）

▐ GitHub Flow

相对Git Flow而言，GitHub Flow只有特性（feature）和主分支（master），当featrue合并到master之后，即部署生产。

优点：分支类型简单，能够频繁部署生产

缺点：没有release分支，没有很好回滚机制保障线上问题快速恢复；对于主干的可发布性保障极高

可能对于一些开源项目/个人项目，不要求过高的稳定性，也不需要预发/生产环境的场景，这种极致的简单，可能开发人员效率会更高一点。

▐ GitLab Flow

在GitHub Flow的基础上，有两个变化：使用环境分支和版本分支，引入了 Pre-production 和 Production 两种发布分支，featrue分支合并到主干不会立即发布，而是主干合并到对应的发布分支上触发对应环境发布：

基于日常/生产环境的工作流程：这种多环境能够让 hotfix 或者 feature 分支能够在发布到生产环境之前被测试，而不像github flow那样简单粗暴。

基于版本分支的工作流程：当需要向外界发布软件时，使用发布分支；尽可能晚的发布一个大版本，这样可以最大限度地减少必须将错误修复应用到多个分支的时间长度；另外，发布分支后，修复错误尽量将错误合并到main分支，避免后续版本发布错误依然存在。

优点：对github flow进行补充，能够对不同项目有合理的分支发布选择

缺点：过于灵活，对于不同项目发布流程相差较大，研发平台很难统一维护

主干研发

主干研发：

团队开发人员之间通过约定向被指定为“主干”的分支提交代码，在变更开发完成后（开发、测试、CR）合并到主干，主干研发要求团队高频率的提交代码，通过持续测试保证主干的可发布性，避免长期存在的多分支导致的开发压力；

一般情况下，发布也是在主干分支进行，当需要隔离不兼容代码的时候，会从主干拉取固定的发布分支。图中红色圆点表示一次坏提交，在构建被破坏后立即被后面的提交修复了。

优点：

降低解决冲突的成本：开发人员在自己的分支上独自工作的时间越长，越难将变更并入主干。另外，当分支个数和每个分支上变更数同时增加时，合并难度会很大。
高质量的代码：日常工作中，不知道大家是否有一个习惯，合并代码通常会在项目的提测或上线前一段时间，日常的合并次数减少，转化到发布前处理大量的合并，以及大量的CR，该流程下，高频次的代码提交合并，将大块的代码切分到日常小块代码和CR，且合并需要通过相关卡口（构建、包依赖等），避免发布前才关注到CR和测试的问题
高效的持续交付：对于大规模的项目，主干分支保持鲜活（其他人的变动能够被及时感知），团队开发效率更好；不用等即可上线，基于特性分支迭代开发的模式，当多个变更集成到迭代时，一个变更完成，另外一个变更没有完成需要退出迭代；测试环境更加稳定，主干研发发布分支在固定分支上，当特性分支迭代有多变更情况，此时，创建的是一个临时发布分支，当有变更加入或退出时，会导致发布的环境不稳定。

缺点：

对团队的基础架构和协作能力的要求很高，要求每次commit的代码能够独立运行，如果合入主干的commit出现问题，会阻塞团队的进度。
对团队代码质量要求高，评审机制要求完善。需要有完善的 CR 机制，将问题代码尽可能在发布的前置环节发现并解决。

前端中可能适合的主干开发的场景

工具函数的开发：

开发阶段：工具函数的需求功能点容易切分，比如 env、cookie 这些工具类函数，可以作为切分为小的代码块，在上线之前通过自动化测试/自测，保证ci通过后，即可快速上线，新增功能；其他人提交功能后，能够及时感知到master的改动点。
发布阶段：主干开发天然基于版本发布，可以支持不同功能的版本
bugfix：基于工具函数的bug，需要快速修复，通过CI后，合并到主干，发布修复的版本，不再拉取新的bugfix分支，解决可能存在的冲突问题。

基于特性开发流程：

基于主干开发流程：

总结

基于主干开发相对于分支开发的各种利弊，根据自己所在团队的实际场景来看待，选择用主干开发还是分支开发。如果主干开发的优势对自身产品可有可无，那么没有这种必要来切换。但是如果有必要，但是团队的成熟度和技能达不到，也不适合切换到主干开发。当选择要切换到主干开发，一定要有心里准备来应对变革过程中遇到的各种问题。当然当你的团队经历了这些阵痛并真正适应了主干开发，那么团队就的成长也是巨大的。