GitFlow工作流

一、 GitFlow 介绍

GitFlow 是一种 Git 工作流，这个工作流程围绕着project的发布(release)定义了一个严格的如何建立分支的模型。它是团队成员遵守的一种代码管理方案 。

Git建分支是非常cheap的，我们可以任意建立分支，对任意分支再分支，分支开发完后再合并。

比较推荐、多见的做法是特性驱动(Feature Driven)的建立分支法(Feature Branch Workflow)。

简而言之，就是每一个特性(feature)的开发并不直接在主干上开发，而是在分支上开发，分支开发完毕后再合并到主干上。

1. 还处于半成品状态的feature不会影响到主干
2. 各个开发人员之间做自己的分支，互不干扰
3. 主干永远处于可编译、可运行的状态

GitFlow则在这个基础上更进一步，规定了如何建立、合并分支，如何发布，如何维护历史版本等工作流程。

二、 GitFlow 常用分支说明

1. 核心分支（永久存在）

这两个分支贯穿项目的整个生命周期，记录了项目的发布与开发状态。

• master (或 main)
  • 含义：生产就绪分支。
  • 状态：master 上的每一次提交，都对应一个已经发布到生产环境的版本。在这里打上 Tag（如 v1.0.0）来标记正式版本。
  • 规则：从不直接提交。只能通过合并 release 或 hotfix 分支来更新。
• develop
  • 含义：集成分支，最新的开发版。
  • 状态：包含了所有已完成的功能，是为下一个版本做最终集成和测试的地方。可以理解为“准发布”分支。
  • 规则：从不直接提交。只能通过合并 feature、release 或 hotfix 分支来更新。当 develop 稳定后，会从中拉出 release 分支。

2. 辅助分支（用完即删）

这些分支有明确的生命周期，诞生于特定目的，完成后必须删除以保持仓库整洁。

• feature (功能分支)
  • 源于：develop
  • 归于：develop
  • 含义：每个新功能都在自己的分支里开发，互不干扰。
  • 命名惯例：feature/登录优化、feature/支付接口
  • 操作：开发完成后，合并回 develop 并删除该 feature 分支。若功能被放弃，分支直接废弃删除。
• release (发布分支)
  • 源于：develop
  • 归于：master 且 合并回 develop
  • 含义：当一个版本的开发接近完成，就开启 release 分支，专门做最后的打磨。这个分支只允许修 Bug、改文档、调配置，禁止加新功能。
  • 命名惯例：release/v1.2.0
  • 双重合并：发布完成后，必须合并到 master（并打上版本标签），然后必须再合并回 develop。因为你在上面修的 Bug，develop 里还没有。合并后删除该分支。
• hotfix (热修复分支)
  • 源于：master
  • 归于：master 且 合并回 develop
  • 含义：这是唯一直接从 master 拉出的分支，用于紧急修复生产环境的严重 Bug。这样修复可以绕过不稳定的 develop，直接从稳定版出发。
  • 命名惯例：hotfix/支付超时崩溃
  • 双重合并：修复测试后，同样需要合并到 master（打新标签）和 develop（确保新版本不会重蹈覆辙）。完成后删除。

3. 完整工作流示例

假设一个新版本 v1.2.0 的开发过程：

1. 开发阶段：从 develop 拉出 feature/A 和 feature/B，开发完合并回 develop，删除这两个分支。
2. 冻结阶段：功能齐备，从 develop 拉出 release/v1.2.0。测试只在 release 分支上进行，修复的 Bug 也在此提交。
3. 发布阶段：release/v1.2.0 测试通过，将其合并到 master 并打上标签 v1.2.0。同时，必须再把它合并回 develop（把修复的 Bug 带回去），然后删除 release/v1.2.0。
4. 紧急修复：线上 v1.2.0 发现严重漏洞。直接从 master 上的 v1.2.0 标签处拉出 hotfix/payment-fix，修复后测试，合并到 master 并打上 v1.2.1，再合并回 develop，最后删除 hotfix/payment-fix。

三、 GitHub Flow对比

如今，随着持续交付理念的普及，许多团队转向了更轻量的 GitHub Flow（只有一个长期分支 main，功能分支合并后立即部署）或 GitLab Flow（引入环境分支）。

但 Git Flow 所定义的“功能分支”、“热修复”等概念，以及“用完即删”的原则，已成为 Git 协作的通用基础。 即便你用的是简化工作流，这些分支的思维模型依然适用。

1. GitHub Flow介绍

GitHub Flow 是 GitHub 官方推荐的一套极简分支工作流，本质是对 Git Flow 的简化与加速。它完全围绕一个长期分支和持续部署来设计，去掉了 Git Flow 中独立的 develop 和 release 分支。

2. 核心定义与原则

GitHub Flow 只有一条核心规则，直接呼应你最初问的“用完即删”：

1. main 分支永远可部署

   • 它是唯一永久存在的分支，上面的一切都是经过测试、随时可以发布到生产环境的代码。
   • 绝不直接向 main 提交，任何改动都从新建分支开始。

2. 从 main 拉出新分支

   • 新功能、Bug 修复、实验，都从最新的 main 创建描述性命名的分支（如 feature/user-auth）。

3. 分支中持续提交并定期推送

   • 频繁将本地提交推送到远程同名分支，相当于时刻备份并公开进度，便于协作。

4. 随时开启 Pull Request

   • 一推送就可以创建 PR，用来讨论代码。即使没写完，也可以在标题上标注 [WIP]（工作进行中），利用 PR 的 diff 和评论功能进行协作。

5. 分支合并前必须经过审查

   • 在合并到 main 之前，别人需要审查并通过。这通常结合 CI 自动化测试，确保分支不会破坏主干的“可部署”状态。

6. 合并后立即部署

   • 这是和 Git Flow 理念上最大的不同。合并到 main 后，应该立刻（或尽快）部署到生产环境。main 的代码始终和线上一致。

7. 合并后立即删除分支

   • 必须删除，以保持仓库干净。这和你最开始的认知完全一致，GitHub 甚至在 PR 页面提供了“合并后自动删除分支”的选项。

3. 对比GitFlow没有的环节

GitHub Flow 去掉了 Git Flow 中的 develop、release 和专门的 hotfix 分支：

• 不需要 develop：所有功能都直接基于最新的 main 来开发。集成不是在 develop 里攒一个版本，而是在 PR 里通过代码审查和自动化测试来保证。
• 不需要 release 分支：因为你合并后就会部署，main 上永远只有当前正在运行的版本。如果要发布旧版本，直接基于当时的 main 打标签（Tag）即可。
• 不需要专门的 hotfix 分支：紧急修复和普通功能一模一样——从 main 拉一个修复分支，测试后合并并部署。只是修复分支名字可能叫 fix/critical-bug，流程上没有特殊地位。

4. 典型流程举例

1. 做新功能：从 main 拉 feature/new-dashboard，开发并推送。
2. 协作审查：创建 PR，CI 自动跑测试，同事检查代码。
3. 上线：审查通过后，合并到 main，立即部署上线，然后删除 feature/new-dashboard。
4. 紧急修 Bug：线上发现仪表盘有漏洞。直接从 main 拉 fix/dashboard-xss，修复、测试、审查，合并到 main 部署，然后删除 fix/dashboard-xss。