分支管理策略

本文共计10240字，预计阅读时间30分钟之内，包含了git-flow/forking workflow/github-flow/gitlab-flow/TBD/TBD++/Aone flow等多种分支管理模型，参考了多方资料

整理不易，给我点个赞吧 o(￣▽￣)ｄ

git-flow model

Vincent Driessen在2010年提出的经典模型

.

主要分支

主分支main

有且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。

开发分支Develop

主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做develop。

develop分支反映了最新的变化，为下一次发布做准备

除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发 [帮助团队成员之间进行并行开发/为产品发布做准备/协助快速解决生产中的实际问题]。临时性分支主要有三种：功能（feature）分支、预发布（release）分支、修补bug（fixbug）分支

这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。

功能分支feature

它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop

• 可以采用feature-*的形式命名

预发布分支-release

它是指发布正式版本之前（即合并到Master分支之前），需要有一个预发布的版本进行测试。

它从Develop分支上面分出来，在此期间只允许bug修复，禁止添加大的新功能，预发布结束以后，必须合并进Develop和Master分支。

• 可以采用release-*的形式命名

修复bug分支-fixbug

软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补，修补bug分支是从main分支上面分出来的。修补结束以后，再合并进main和develop分支

• 可以采用 hotfix-* / fixbug-* 的形式命名

.

优缺点

优点：各分支权责分明，清晰可控，是很多分支管理策略的启蒙模型。

缺点：

1. 合并冲突：同时长期存在的分支可能会很多：main、develop、release、hotfix、若干并行的feature分支。两两之间都有可能发生冲突。频繁手动解决冲突不仅增加工作量，而且增大了出错的风险。
2. 功能分离：功能并行开发时，合并分支前无法测试组合功能，而且合并后可能会出现互相影响。
3. 无法持续交付：git-flow更倾向于按计划发布，一个feature要经历很多步骤才能发布到正式环境，难以达到持续交付的要求。
4. 无法持续集成：持续集成鼓励更加频繁的代码集成和交互，尽早解决冲突，而git-flow的分支策略隔离了代码，尽可能推迟代码集成。

.

Forking Workflow

Forking Workflow 是一种基于 GitHub（或 GitLab、Bitbucket 等平台）的协作模型，其核心思想是：

每个开发者都拥有上游（upstream）项目的完整副本（即 fork），在自己的副本上开发，再通过 Pull Request（PR）/Merge Request（MR）向原项目提交更改。

.

流程：

1.Fork 原仓库
在 GitHub 上点击 Fork，将 original/project 复制到你的账号下 → yourname/project

2.克隆你自己的 fork 到本地

git clone https://github.com/yourname/project.git
cd project

3.添加 upstream 远程（可选但推荐）

git remote add upstream https://github0.com/original/project.git

用于同步原仓库的最新变更。

4.创建分支 并开发

git checkout -b fix-typo
# 修改代码...
git commit -am "Fix typo in README"
git push origin fix-typo

5.在 GitHub 上发起 Pull Request
从 yourname/project:fix-typo → original/project:main

6.维护者审查、讨论、合并

7.同步更新（后续）

git fetch upstream
git checkout main
git merge upstream/main
git push origin main  # 更新你的 fork

.

Forking Workflow 对开源的重要性：

• 权限隔离：原项目维护者无需给成千上万的贡献者分配写权限。
• 安全可控：所有代码变更必须通过 PR 审查才能进入主干。
• 独立开发环境：每个贡献者有自己的“沙盒”，不会干扰主仓库。
• 天然支持分布式协作：符合开源“去中心化”的精神。

.

Github-flow model

Github.com使用的工作流程

Vincent Driessen在2020年3月5日对git-flow model模型又做了一些说明：由于gitflow-model更适合多个版本并存的场景，但现如今的web应用很少会需要多版本并存，更多的是一个版本持续交付，因此推荐使用更简单的模型，例如GitHub flow。

版本持续交付：代码一有变动，就部署一次。这时，main分支和develop分支的差别不大，没必要维护两个长期分支

GitHub flow是一个轻量级的、基于分支的工作流。是 Github 使用的工作流程。 它只保留一个主分支main，开发新功能时基于main创建一个feature分支，开发完成后发起Pull-Request。审核通过后合并回main分支，并进行部署。

.

原则：

• 主分支（main / master）始终可部署
• 所有开发都在新分支（feature branch）上进行
• 分支命名要有意义（如 add-login-button）
• 通过 Pull Request 合并回主分支
• PR 要经过代码审查、CI 通过后才能合并
• 合并后立即部署（具备部署能力）

.

流程：
1.根据需求，从main拉出新分支(feature分支/bug分支)
2.开发，push到该分支
3.新分支开发完成后，或者需要讨论的时候，就向main发起一个pull request（PR）。

4.你的Pull Request被接受，合并进main，重新部署后，删除原来你拉出来的那个分支

.

主要分支

main分支

所有提供给用户使用的正式版本，都在这个主分支上发布。

新分支

从master拉出新分支（不区分功能分支或补丁分支）

在这个分支上进行修改，然后发起PR，合并修改会主分支

优缺点

优点：

1.分支简单，只有master主分支，和feature分支，降低了分支管理的复杂度。
2.符合持续集成：尽早反馈、有问题尽早解决，集成周期短。

缺点：

1.只有一个master分支，使得版本管理、部署管理工作变得复杂

Github-flow model 和 Forking Workflow的区别

Github-flow仅适用于你有该仓库的写权限（write access） 的情况（比如你是团队成员、协作者，或项目是你自己的）。

对比：

• 如果在 自己有写权限的仓库（比如公司项目、个人项目）中工作 → 可用方式 2（GitHub Flow）✅
• 如果在 没有写权限的公共仓库（比如给 React、Vue 提 PR）→ 必须用方式 1（Fork + PR）✅

.

Gitlab-flow model

Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法

特性

1.上游优先
只存在一个主分支，是所有分支的上游，只有上游采纳的代码变化，才能应用到其他分支

2.持续发布

对于"持续发布"的项目，它建议在main分支以外，再建立不同的环境分支。比如，"开发环境"的分支是main，"预发环境"的分支是pre-production，"生产环境"的分支是production。

开发分支是预发分支的"上游"，预发分支是生产分支的"上游"

由"上游"向"下游"发展。比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到main，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。

.

主要分支

主分支main
日常开发在main上面完成

功能分支feature

在main分支的基础上创建出来，用于开发某种特定功能，开发完合并回main分支，并删除这个功能分支

• 可以命名为feature-x

稳定的版本分支stable

命名为x-x-stable

pre-production分支

.

结构选择

持续发布的项目(大部分web项目)，建议使用的结构：

在master分支以外，再建立不同的环境分支

“多版本”发布的项目，建议使用的结构：

对于“多版本发布”的项目，建议每一个稳定版本，都从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。

以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。

优缺点

优点

1.简化了发布、标记和合并的过程，提高了部署上线的效率

2.提交自然的向下游流动，确保每次更改在进入生产环境之前都经过测试

3.不引入不必要的复杂性，适合各种工作流程

Trunk based Development主干开发

简称TBD

在持续集成（CI）和持续交付（CD）成为行业标配的今天，如何设计高效的 Git 分支管理模型，直接影响着团队的交付速度与产品质量。主干开发（Trunk-Based Development, 简称 TBD） 正是在这一背景下被广泛推崇的一种轻量级、高效率的开发模式。

特点

• 单一主干：存在一个主干分支，所有开发基于主干，要求所有的提交尽快回到主干

• 短生命周期分支：如有必要创建分支（如发布或修复），也应尽可能短暂，并快速合并回主干。

• 随时可发布：主干上的任意提交都应处于“可部署”状态，支持高频发布

  发布时直接从主干分支上创建release分支，并打上tag，发布完成后删除release分支。即，发布分支是主干分支某个时点的快照。

作用：

• 减少合并冲突：共享最新的代码，并且能尽可能地减少合并冲突；

• 快速反馈：主干始终代表最新状态，问题能尽早暴露。

• 简化流程：无需复杂的 PR 审批链或多级分支管理，适合敏捷迭代。

• 保证了代码版本随时处于可发布的状态，有利于持续集成和持续交付。

• => 提升了交付效率

问题与解决

1. 如何避免发布未完成的feature：使用Feature Toggle —— 在代码中增加一个特性开关来控制新特性的打开与关闭。

2. 如何修复线上bug：发布时打tag，如果这个版本出现问题，如果master分支没有新的提交，就直接在master分支上修复，然后合并到release分支；如果master分支已经有新提交了则：

   • 从tag处创建release分支

   • 在master上修复bug

   • 将修复bug的提交cherry pick到release分支

     

   • 在release分支上打tag并发布

适用场景

• 团队规模适中、成员水平较高：能自觉编写可集成的代码。
  TBD没有pull或者push request，要求开发人员尽快把代码提交到主干分支，缺乏严格的流程来保证每一份提交代码的质量，如果一些项目开发人员众多且水平不一，同时工作在主分支上可能会在产品发布时才发现不可预知的问题
• 追求快速迭代：如互联网产品、SaaS 服务。
  适用于需要快速迭代的产品，如果在主干分支上发现问题，可以快速进行修复再合并回主干分支。
• 具备完善的自动化测试与 CI/CD 流水线：确保每次提交的质量。

反之，若团队缺乏自动化保障，或成员经验参差不齐，盲目采用 TBD 可能导致主干“污染”，反而降低稳定性

TBD++ flow

在某些大型项目中（如电信级软件），需求既要求前期快速迭代，又要求后期有稳定的交付版本，且存在大量客户定制化需求。纯 TBD 可能难以兼顾灵活性与稳定性。

为此，Arrus 公司自 2015 年起实践并完善了 TBD++ 模型，融合了 TBD 的敏捷性与 Git Flow 的发布控制能力。

特点

核心设计

1. 以主干为核心，辅以短期功能/修复分支

• 主干（master）：始终包含最新功能，通过自动化测试保证基本可用性，但不承诺每个提交都“生产就绪”。
• Feature 分支
  • 从 master 创建，用于开发新功能。
  • 开发过程中需定期同步 master，避免后期大冲突。
  • 完成后经代码评审 + 功能测试，由开发者自行合并回 master（无需管理员审批）。
• Bugfix 分支
  • 用于修复 master 上的问题，流程同 Feature 分支。

关键理念：质量靠测试与评审保障，而非权限控制。

为及时发现问题，每次主干提交都会触发系统级自动化测试，并辅以定期人工回归测试。若引入严重问题，专职配置管理员（SCM）可选择回滚或创建紧急修复分支。

2. 独立的 Release 分支用于稳定发布

• 当 master 包含某版本所需全部功能且无严重缺陷时，由 SCM 从主干创建 release/x.y 分支。
• Release 分支只允许修复、文档、配置等发布相关变更，禁止新功能。
• 所有修复需同时合并回 master，确保主干完整性。
• 发布前，SCM 可选择性地将 master 中的关键修复 cherry-pick 到 release 分支。
• 发布时，在 release 分支上打 tag（如 v2.1.0）。

3. Hotfix 流程

• 若已发布版本出现严重问题：
  • 基于该版本的 tag 创建 hotfix 分支。
  • 修复后合并回对应 release 分支，并打新 tag（如 v2.1.1）。
  • 同时合并回 master，避免问题重现。

对比

AoneFlow

摘录自https://juejin.cn/post/6844904203115036685

AoneFlow是阿里内部使用的代码分支管理策略，“它基本上兼顾了 TrunkBased 的‘易于持续集成’和 GitFlow 的‘易于管理需求’特点，同时规避掉 GitFlow 的那些繁文缛节”。

AoneFlow 只使用三种分支类型：主干分支、特性分支、发布分支。一个完整的流程如下：

1. 从主干上创建一个特性分支（前缀为feature/），然后在这个分支上进行代码开发。可能会有多个特性分支并行开发。

2.从主干上创建一个发布分支（前缀为release/），将所有要发布的特性分支合并到发布分支上。发布分支可以有多个，分别对应不同的环境，如release/test分支对应部署测试环境，release/prod分支对应线上正式环境等等。也可以一个发布分支对应多个环境。发布分支的特性组成是动态的，例如某个功能或特性因为某些原因无法如期发布，可以删除这个分支，再从主干重建一个同名发布分支，只把需要发布的特性分支合并过来。发布分支之间松耦合，可以将不同的特性组合发布到不同的环境中。

3.发布分支发布到线上后再合并回主干分支，并在主干分支打上标签，最后删除与该发布分支关联的特性分支。

策略选择

补充说明：

• TBD++ 可视为 TBD 与 AoneFlow/GitLab Flow 的混合体，强调主干敏捷 + 发布分支稳定，在表格中其特性已部分融入 TBD 和 AoneFlow 的描述。
• AoneFlow 的关键创新在于：用“一次发布 = 一个 release 分支”替代 Git Flow 的复杂层级，既保持主干干净，又支持灵活的多版本管理，是阿里内部大规模工程实践的产物。

参考资料

https://www.ruanyifeng.com/blog/2012/07/git.html

https://nvie.com/posts/a-successful-git-branching-model/

https://juejin.cn/post/6844904203115036685

https://www.ruanyifeng.com/blog/2015/12/git-workflow.html

https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/