1. Git Flow
1.1. 简要说明
这是最经典、最严谨的工作流，由Vincent Driessen在2010年发明，适合有固定周期发布的传统项目。
1.2. 流程示意图
1.3. 核心特点
1.3.1. 核心分支（长期存在）
- main：存放正式发布的版本（每个标签对应一次上线）。
- develop：存放最新的开发代码，集成所有功能（用于做代码合并和集成）。
1.3.2. 辅助分支（临时存在）
- **feature/***：从 develop 拉出，开发新功能，完成后合并回 develop。
- **release/***：从 develop 拉出，准备发布（只修 Bug、写文档、调整版本号），完成后合并到 main（打标签）和 develop。
- **hotfix/***：从 main 拉出，紧急修复线上问题，完成后合并到 main（打标签）和 develop。
1.4. 优缺点
1.4.1. 优点
- 在项目周期之内，该工作流保证任何时刻两个主要分支都是处于纯净状态的。
- 由于遵循系统化的模式，因此分支命名容易理解。
- 大多数Git工具都支持该工作流的扩展工具。
- 当项目中需要同时维护多个生产版本时，该工作流模式非常理想。
1.4.2. 缺点
- Git 的历史记录将变得异常混乱，可读性很差。
- master / develop 分支的割裂使CI/CD流程变得更加困难。
- 当项目维护单一生产环境版本时，该工作流则不适用。
1.5. 适用场景
适合有固定周期发布的传统项目，且周期较长，通常大于一个月。如：操作系统的开发。不太适合敏捷开发。
2. GitHub Flow
2.1. 简要说明
GitHub Flow这是最流行的“简化但规范”的工作流，是GitHub首推的方式，由GitHub在2011年创建。
2.2. 流程示意图
2.3. 核心特点
- main(或master)分支：始终可部署的稳定版本。
- 所有开发都在功能分支上进行（分支名如 feature/login - page）。
- 功能完成后，通过Pull Request (PR) 请求合并，经过代码评审和 CI 检查后才能合入main分支。
- 一旦新分支被合并推送至main分支，main分支应当立即进行部署（或触发部署流程）。
2.4. 优缺点
2.4.1. 优点
- 该工作流对于CI/CD流程友好。
- 是Git工作流的一种简版替换。
- 当项目维护单一生产环境版本时，该工作流适用。
2.4.2. 缺点
- 生产环境对应的代码极易处于不稳定状态。
- 对于依赖发布计划的项目无法充分支持。
- 该工作流并不涉及关于部署，环境，发布和问题等方面的解决方案。
- 没有明确支持“多版本并行维护”，不适合需要同时维护 v1.0（修 Bug）和开发 v2.0（新功能）的场景。
2.5. 适用场景
- 持续交付、Web 应用、API 项目、以及中小型开源项目。
- 单个环境，需要敏捷开发的场景。
3. GitLab Flow
3.1. 简要说明
GitLab Flow 是 GitLab 官方推荐的一种轻量级 Git 工作流，旨在解决 Git Flow 过于复杂和 GitHub Flow 过于简单的问题，为团队提供了一套清晰、高效且透明的最佳实践。
3.2. 流程示意图
3.3. 核心特点
3.3.1. 主要分支
- 主分支（main / master）
- 唯一长期存在的主干分支。
- 始终保持可部署状态。
- 所有代码最终合并到这里。
- 通常受保护，禁止直接推送。
- 环境分支（Environment Branches）：这是 GitLab Flow 的特色之一，按部署环境划分：
- production：生产环境代码（可选，可直接用 main）。
- pre - production / staging：预发布/测试环境。
- main：开发环境（最新功能）。
- 功能分支（Feature Branches）：
- 从 main 创建：git checkout -b feature/xxx main。
- 命名规范：feature/描述、fix/描述、chore/描述。
- 生命周期短，合并后即删除。
3.3.2. 分支保护策略
- main、production 等长期分支必须受保护。
- 禁止直接推送（Force Push）。
- 要求 MR 才能合并。
- 可配置：要求最少 Approval 数、必须通过 CI。
3.4. 优缺点
3.4.1. 优点
- 和 CI/CD 流水线完美匹配。
3.4.2. 缺点
- 仍然可能需要维护多个长期分支。
3.5. 应用场景
- 需要严格区分开发、预发、生产等不同环境的项目。
- 需要有多个不同的分支进行迭代更新的项目。
