Git Flow：什么是它，分支模型以及在项目中的应用

什么是 Git Flow？

Git Flow — 是一个 Git 分支模型，为管理开发、发布和修复定义了严格的分支结构和合并规则。Vincent Driessen 于 2010 年 1 月发表了文章《一个成功的 Git 分支模型》，从此 Git Flow 成为企业 Java 和 .NET 开发的事实标准。核心思想 — 将代码分为五种具有不同稳定性级别的分支类型。

根据 Atlassian Git 教程，2024，Git Flow 基于两个永久分支：main（以前是 master）和 develop。所有其他分支都是临时的：feature、release、hotfix。每种分支类型都有明确定义的生命周期和合并规则。在移动开发中，Git Flow 应用于具有定期发布周期（2-4 周）和支持多个版本的项目。

Git Flow 与简单模型（GitHub Flow）的不同之处在于它需要一个单独的 develop 分支进行集成。这为合并过程增加了一个步骤，但为未完成的功能提供了额外的隔离，使其与准备发布的代码分开。

Vincent Driessen 和 Git Flow 的历史

2010 年，Vincent Driessen 发表了《一个成功的 Git 分支模型》的帖子，成为 Git 历史上被引用最多的文章之一。该模型是为一个具有固定发布和并行版本支持的项目创建的。2020 年，Driessen 承认 Git Flow 对于现代 CI/CD 实践已经过时，但该模型对于具有长发布周期和需要支持旧版本的项目仍然具有现实意义。

# 初始化 Git Flow
git flow init

# 创建 feature 分支
git flow feature start "add-auth"

# 完成 feature 分支（合并到 develop）
git flow feature finish "add-auth"

# 创建 release
git flow release start "1.2.0"
git flow release finish "1.2.0"

Main 分支：发布代码和标记

Main（以前是 master）— 包含仅准备部署的发布代码的主分支。main 中的每次提交必须对应产品的特定版本，用语义化版本格式的标记（tag）标识，例如 v1.0.0、v1.1.0。main 中不进行任何直接开发 — 更改仅通过 release 或 hotfix 分支进入这里。

根据 semver.org，2024，main 中的标记使用 MAJOR.MINOR.PATCH 格式。MAJOR 在不兼容的 API 更改时增加，MINOR — 在添加向后兼容的功能时增加，PATCH — 在修复错误时增加。在 Git Flow 中，每次 finish release 都会自动在 main 中创建一个带有版本标记的提交。

Main — 唯一部署到生产环境的分支。对于移动项目，这意味着当推送到 main 时，将启动构建 App Bundle 或 IPA 并发布到 Google Play / App Store 的流水线。在 GitLab 的 CI/CD 设置中，main 受到保护，防止强制推送和删除。

语义化版本控制和标记

main 中的每次提交都带有一个 标记，格式为 SemVer：vMAJOR.MINOR.PATCH。MAJOR — 用于不兼容的 API 更改，MINOR — 用于具有向后兼容性的新功能，PATCH — 用于错误修复。示例：v2.1.0 表示带有新功能且没有错误修复的第二个主要版本。在 Git Flow 中，标记在完成 release 或 hotfix 时通过 git flow release finish 命令自动创建。

Develop 分支：开发集成线

Develop — Git Flow 的第二个永久分支，用于集成所有完成的功能。开发人员在通过代码审查和 CI/CD 检查后将 feature 分支合并到 develop 中。Develop 包含最新稳定版本的代码，包括当前 sprint 中所有已实现的功能。

根据 DataSift Git Flow 指南，2024，由于未完成的集成，develop 可能暂时不稳定。为防止问题，团队实践持续集成（CI）：每个功能在合并到 develop 之前都会经过完整的测试集。如果 CI 失败 — 开发人员在下次合并之前修复代码。Develop 始终与 main 的当前版本关联：发布后，develop 立即通过合并与 main 同步。

Feature 分支：开发新功能

Feature 分支 — 用于开发单独功能、错误修复或实验的临时分支。每个 feature 分支从 develop 创建，完成后合并回 develop。Feature 分支的名称通常包含任务编号或简短描述：feature/APP-123-add-oauth、feature/redesign-profile。在 Git Flow 中，feature 分支可以无限期存在。

根据 Pro Git Book，2024，feature 分支是一个隔离的开发环境：一个分支中的更改在合并之前不会影响其他分支。在移动项目中，feature 分支通过 rebase 或 merge 与 develop 同步，以避免在完成时出现大的冲突。建议在创建 MR 之前将 feature 分支 rebase 到 develop 上。

# 手动创建 feature 分支（不使用 git flow）
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# 通过 CLI 在 GitLab 中创建 MR
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Release 分支：准备发布

Release 分支 — 从 develop 创建的临时分支，用于准备发布。当 develop 包含足够的新版本功能集时，团队创建 release/X.Y.Z 分支（例如 release/2.1.0）。在此分支中只进行最终更改：版本号增加、本地化更新、最终测试、关键错误修复。

根据 Atlassian Git 教程，2024，release 分支解决了一个关键问题：将最终更改与并行开发隔离。在 prepare 准备发布时，develop 中继续合并下一个发布的新功能。完成后，release 分支合并到 main（带标记）和 develop（以同步版本号增加）。

Hotfix 分支：生产中的紧急修复

Hotfix 分支 — 用于紧急修复生产中关键错误的临时分支。唯一一种从 main 而不是从 develop 创建的 Git Flow 分支类型。名称格式：hotfix/X.Y.Z+1（例如 hotfix/2.1.1）。完成后，hotfix 分支同时合并到 main（作为新的补丁发布）和 develop（以便修复不会在后续发布中丢失）。

根据 DataSift Git Flow 指南，2024，hotfix 分支应尽可能短 — 只有修复和测试。Hotfix 不应包含新功能或重构。在移动开发中，hotfix 用于修复关键崩溃（crash rate > 0.1%）、安全漏洞或 App Store 中的阻塞错误。

Git Flow 在移动开发中的优缺点

Git Flow 提供了清晰的结构，对大型团队和具有定期发布的项目特别有用。优点：在 feature 分支中隔离未完成的功能，可以在不阻塞开发的情况下准备发布，通过 hotfix 支持多个版本。缺点：对初学者来说复杂，需要定期 rebase feature 分支，长期存在的分支会产生冲突。

根据 Martin Fowler，2024，Git Flow 的主要缺点 — 长期存在的 feature 分支。如果功能开发 2 周以上没有与 develop 同步，合并时的冲突就会变得严重。对于移动项目，建议每天通过 rebase 到 develop 来同步 feature 分支。

Git Flow 不建议用于持续部署（每次提交到 main → 到生产）的项目。对于此类项目，GitHub Flow 或 Trunk-Based Development 提供更简单、更快速的模型。但对于具有发布周期和旧版本支持的项目，Git Flow 仍然是最佳选择。

Git Flow 何时对团队有害

Git Flow 在三种情况下成为 问题：团队少于 5 人（过于复杂）、持续部署（交付延迟）、缺乏 rebase 纪律（长期存在的 feature 分支产生合并冲突）。如果团队花费超过 20% 的时间在合并分支和解决冲突上 — Git Flow 不适合该团队，即使是大型团队也不行。

Git Flow 的替代方案：GitHub Flow 和 Trunk-Based Development

Git Flow 的替代方案 为实践 CI/CD 的团队提供更简单的流程。GitHub Flow 只使用一个永久分支（main）和 feature 分支。每个功能从 main 创建，经过审查和 CI 后合并回 main 并立即部署。GitHub Flow 更简单，但不支持未完成功能的隔离和并行发布准备。

根据 GitHub 文档，2024，Trunk-Based Development（TBD）更进一步：所有开发人员在一个分支（trunk）中工作，使用 1-2 天的短期 feature 分支。Feature toggles（功能开关）控制未完成代码的可见性。TBD 需要高 CI/CD 纪律和测试自动化。

• GitHub Flow — 一个 main + feature 分支，非常适合 CI/CD 和小型团队
• GitLab Flow — 通过环境分支（staging、production）扩展 Git Flow
• Trunk-Based Development — 一个分支 + feature toggles，最大化 CI/CD，最小化合并
• One Flow — 没有 develop 分支的简化 Git Flow，只有 main + feature + release