Git Branching Strategies: Git Flow, GitHub Flow, GitLab Flow, TBD

完整介绍 Git 分支策略 feat. Git Flow、GitHub Flow、GitLab Flow、待定

@ Git

前言

近期在维护不同规模的项目，想说可以了解一下不同 Git 分支策略的优缺点来替项目选择合适的开发策略。现阶段我最常接触的是 Gitflow 的方式来进行开发，但发现这样的策略在小型规模的项目（5 人以下）并没有这么灵活好用，恰巧可以在全新的项目上尝试其他策略，观察现有的分支策略痛点是这样：

  • 对于刚起步的简单项目来说相对过于复杂的流程
  • 太多的长分支，项目难有一个确定的开发中版本。
  • 害怕巨无霸分支合并后会不会有新问题冒出来。

有的人喜欢 GitFlow 有的人超讨厌，而我想在这篇文章敞开想法去分析了解不同策略的优缺点。

Gitflow

Gitflow 是一种全面的分支策略，旨在覆盖各种场景。开发者们创建以功能为单位的 feature 分支并且在完成时合并入 develop 分支，并且在需要发布时创建 release 分支用于测试调整，最终合并到主分支 main 并且正式发布（可以添加标签用于标注版本）。

当发布后发生紧急问题时，会从 main 开一个 hotfix 分支出来进行修复，修复完成之后，会合并回 main 分支，也同时会合并一份到 develop 分支。

  • 优点：
    • 可预测的发布周期：从开发到测试到发布周期都非常明确，非常适合具有定期开发和发布节奏的团队。
    • 增强合作：通过不同明确职责的分支分隔出特定的环境，适合大型团队以及跨多个团队的协作并行开发。
    • 有效处理多个产品版本：通过释出分支和修补分支，Gitflow 使得团队可以同时支持多个版本。比如，团队可以在开发新版本的同时，维护和更新已发布的旧版本，确保所有版本都能及时得到支持和修补。
  • 缺点：
    • 流程相对复杂：由于分支众多，管理分支对初学者或新团队来说会提高负担。
    • 发布周期相对缓慢：频繁的短分支使用 Gitflow 意义不大，因此长分支是常态。缓慢的发布周期可能意味着更慢的反馈。
    • 合并冲突：长分支有可能导致分支间差异过大，更容易在分支合并时造成冲突。

GitHub Flow

GitHub Flow 围绕在一个活跃的开发分支通常是 main 运行，这个分支会直接部署到生产环境。功能和 BUG 修复是通过功能分支来实现的。这种方法鼓励反馈循环和异步协作，在开源项目中很常见。

通常会用到一些 GitHub 平台提供的一些功能，例如 Pull Request（拉取请求，要求对方把自己代码纳入项目中）、Fork（复制项目一份到自己的远端储存库）、代码审核（针对 PR 的讨论功能）……等。

  • 优点：
    • 直觉且简单：减少了分支管理的复杂性。
    • 快速反应与反馈：精简的流程，适合快速开发和频繁部署，可以更快的得到反馈。
    • 非常适合中小型团队中的异步工作：由于流程简单直接不需要等待长时间的集中合并，因此非常适合小型团队中的成员进行异步工作。
  • 缺点：
    • 正式环境更容易出问题：在没有适当测试和健全的 CI/CD 、代码审核……等过程下更容易发布问题到生产环境。
    • 适合单一版本产品：基于简单的结构，同时维护与管理多个发布版本变得困难。

GitLab Flow

GitLab Flow 是 GitHub Flow 的变体，基本流程相同。

不过为了解决 GitHub Flow 在多版本或多状态管理上的问题进行了一些调整，举例来说开发者们会持续的推送进度到 main 分支上，当有预备要发布的需求时通过挑选进度到不同用途的分支上的方式来解决部属和版本管理的问题，例如：staging 分支用于测试环境、production 分支用于正式环境。

  • 优点：
    • GitHub Flow 的所有优点
    • 可应对不同版本和多环境。
  • 缺点：
    • 比 GitHub Flow 复杂一点

Trunk Based Development

主干开发（Trunk Based Development）提倡使用单一共享的主干分支，并消除长期存在的分支，在需要发布时直接从主干构建 release 分支部署。根据团队规模的不同，这种方法有两种变体：较小的团队直接提交代码到主干，而较大的团队则创建短期的功能分支，鼓励频繁整合较小的功能片段，以确保经常进行合并。

尽可能的快速迭代把问题给刷掉，减少了烦恼分支合并、测试环境与版本，强烈依赖团队素质通过自动化测试来维持稳定。

  • 优点：
    • 追求极致快速的迭代与反馈
  • 缺点：
    • 依赖强大的自动化 CI / CD 与团队素质来保证稳定性。
    • 有时候会需要功能切换🔗的机制，以避免未完成的功能出现在正式环境。

总结

我发现几个重点因素可以帮助我们选择适合的分支策略：项目类型、团队素质、团队种类。

  • 团队素质：如果团队具有强大的技术能力和自动化测试，主干开发可能是一个不错的选择，它追求极致快速的迭代和反馈，并依赖强大的自动化 CI/CD 来保证稳定性。然而，如果团队尚未具备这些能力，则较为结构化的策略如 Gitflow 可能更适合，因为相较之下能提供更明确的分支管理和发布周期。

  • 团队种类：大型团队和跨团队合作的情况下，Gitflow 可能更适合，因为能将开发、测试和发布流程清晰地分隔开来，并且支持同时维护多个版本。而对于中小型团队或适应性较强的团队，GitHub Flow 或 GitLab Flow 可能更适合，由于较少的流程和较快的反馈，适合快速开发。

  • 项目类型：对于需要同时维护多个版本的软件，Gitflow 可能更适合，因为它支持多版本的同时开发和维护。对于敏捷开发或需要快速迭代的项目，GitHub Flow 或 GitLab Flow 可能更适合，因为它们能够提供较快的反馈和灵活的开发流程。

延伸阅读