Git版本分支管理-开发模式介绍

Git开发模式分类

开发模式从本质上可以分为两类: 特性分支开发模式(Feature Branch Development)和主干开发模式(Trunk Based Development).

特性分支开发模式

介绍

特性分支开发模式是指为一个或多个特定的需求 / 缺陷 / 任务创建代码分支（branch），在其上完成相应的开发（一般经过增量测试）后，把它合并（merge）到主干 / 集成分支的开发模式。

通常这种分支生命期会持续一段时间，从几天到几周不等，极少数情况甚至以月算。

以Git-Flow为例:

优点

特性开发周期宽松：因为生命期可以较长，较大的需求特性可以在宽松的时间内完成再合入主干；

分支测试的时间宽松：因为生命期可以较长，可以有较多时间对分支进行测试，甚至手工测试；

缺点

分支管理复杂：原因在于大量采用代码分支，且来源分支和合入目标分支各异，操作复杂 —— 以上图为例，可以从 master（Tag 1.0.0） 拉出 hotfix 1.0.2 分支，然后合入到 develop 分支，开发阶段结束后合入到 release branches，发布后合入 master，非常复杂，很容易出错；

合并冲突多、解决难：分支生命期越长，意味着与主干的代码差异越大，冲突概率越高，冲突的解决难度越大（甚至成为不可能）；

迭代速度慢：特性分支生命期长（数天至数周）意味着特性上线速度慢，相应的迭代速度也慢；

需要较多测试环境：每个特性分支都需要分配至少 1 个测试环境，且长期占用（有状态）；

适用环境

对版本迭代速度要求不高

测试自动化程度低，或说主要靠人工测试的

常用模式

Git-Flow, Github-Flow, Gitlab-Flow

主干开发模式

介绍

主干开发，是指开发人员直接向主干（习惯上主干分支通常为：trunk 或 master）提交 / 推送代码。通常，开发团队的成员 1 天至少 1 次地将代码提交到主干分支。在到达发布条件时，从主干拉出发布分支（通常为 release），用于发布。若发现缺陷，直接在主干上修复，并根据需要 cherry pick 到对应版本的发布分支。

以TBD Flow为例:

优点

分支模型简单高效，开发人员易于掌握不容易出现错误操作

避免了分支合并、冲突解决的困扰

随时拥有可发布的版本

有利于持续集成和持续交付

缺点

基础架构要求高：合入到主干的代码若质量不过关将直接阻塞整个团队的开发工作，因此需要高效的持续集成平台进行把关；

自动化测试要求高：需有完备单元测试代码，确保在代码合入主干前能在获得快速和可靠的质量反馈；

最好有代码评审：若代码质量要求高，需要配套代码评审（CR）机制，在代码提交到主干时，触发 CR，通过 Peer Review 后才能正式合入；

最好有特性开关：主干开发频发合入主干的情况下，特性拆分得很小，可能是半成品特性，需要配套特性开关（Feature Toggle），只有当特性整体开发完才通过灰度发布等手段逐步打开；

适用环境

对迭代速度要求高，希望需求快速交付上线

基础架构强，持续集成工具高效；

团队成员习惯 TDD（测试驱动开发），代码自动化测试覆盖率高（至少增量代码的自动化测试覆盖率高）；

常用模式

TBD Flow, TBD++ Flow