概述

以Git 为代表的版本控制系统可以使开发者能够跟踪、管理和组织自己的源代码。

在现代级软件开发中，速度和敏捷性对于开发和发布软件系统至关重要。但是，当你有一支为数不少的开发团队同时工作时，分支和合并代码的场景会很快变得混乱。

因此，团队需要制定分支流程来一次实施多项变更，这就需要拥有高效分支策略，成为每个研发团队优先处理的事项。

关于 Git 分支

使用Git 版本控制系统时，软件开发团队在编写、合并和部署源代码时需要建立和使用分支策略。

从本质上来说，分支策略是开发人员在与共享代码库交互时要遵循的一组规则。当多个开发人员协作工作，并且同时添加他们的更改时，保持存储库的组织架构，采用分支策略以防止应用程序中的错误和合并产生的超级复杂度。

这一类的合并冲突阻碍了开发人员快速发布代码，也就是上线产品，也阻碍了创建和维护 DevOps 流程。

坚持正确的分支策略，开发人员能够顺利的协同工作，无需管理彼此交叉的代码行。在修改源代码控制时，创建一个清晰的分支流程，允许团队并行工作，并以更快的发布效率，减少更少冲突。

“分支（Branch）”的概念是指从主分支分支出来的独立代码行，允许开发人员在合并更改之前独立工作。

为什么需要分支策略

综前所述，制定一个分支策略是必要的，可以有效避免合并冲突，并且能更容易地将更改集成到主分支中。

我们来总结分支策略的目标：

• 确保开发人员之间的协调流畅来提高生产力；

• 启用并行性开发；

• 帮助组织一系列有计划的、结构化的发布；

• 在对软件进行更改到生产环境时，绘一条清晰路径；

• 维护无错的代码，开发者在其中快速修复问题，并将这些更改重新投入生产环境，不会中断开发流程。

有哪些常见的分支策略

Git 分支的最大优势在于它是“轻量级”的。这表示数据将由一系列快照组成，每次提交时，Git 都会抓取文件当时的样子，存储对该快照的引用。这表示这些分支不是文件系统的副本，而只是指向最新提交的指针。这增加了一层新的灵活性，你可以采取任何方式来定义自己的策略。

以下是一些经过实战考验和主流的分支策略策略：

1) GitFlow

对于当今的许多项目来说，GitFlow 被认为有点复杂，但它着一些先进性，它支持并行开发，开发人员可以在从主分支创建功能分支与主分支分开工作。

之后当更改完成时，开发人员将这些更改合并回主分支以进行发布。

除了主分支之外，它还支持分支，包括功能、发布和修补程序。这些分支具有有限的生命周期和严格的使用规则。

功能分支合并到develop分支。它用于特定功能完成后合并回来，它用于完成所有内容并修复小问题。当代码准备好发布时，它被合并到master。

修补程序分支用于需要在发布代码中修复问题或紧急错误。它们从master分支，完成后合并回master，并与develop分支合并。

优点

• 
  

• 保护生产代码；

• 当开发人员在单独的分支上工作时，允许主分支保持稳定以供发布；

• 各种类型的分支使开发人员更容易组织他们的工作；

• 处理多个版本的生产代码时的理想选择；

• 系统的开发过程允许进行有效的测试。

缺点

• 开发周期可能会减慢；

• 这不是团队实施持续集成和交付的有效方式；

• 随着更多分支的添加，随着开发人员将他们的更改从开发分支合并到主分支，它们可能变得难以管理；

• 当开发人员迷失在提交的海洋中时，要弄清楚问题出在哪里将变得越来越困难。

2）GitHub stream

它是一种更简单的替代方案，非常适合小型团队，不需要管理多个版本。与 GitFlow 不同，此模型没有发布分支。我们从主分支开始，然后开发人员创建分支，直接源自主分支的功能分支，来隔离成员的工作，然后将其合并回主分支，然后再删除功能分支。

该模型背后，主要思想是将主代码保持在恒定的可部署状态，因此可以支持持续集成和持续交付流程。

优点

• 最简单的策略之一；

• 它支持持续交付和持续集成；

• 非常适合小型团队和 Web 应用程序。

缺点

• 
  

• 无法同时支持生产中的多个版本代码；

• 缺乏专门的开发分支，使得 GitHub 流程容易受到生产中错误的影响；

• 主分支容易变得混乱，因为它既是生产分支又是开发分支；

• 但是随着扩展，管理许多拉取请求变得具有挑战性；

• 对于更大的团队，许多开发人员正在开发自己的功能分支，并且在将它们合并回来时，他们可以互相冲突；

• 它还需从分支而不是主分支进行测试和部署，可能并不适合所有团队。

3）GitLab Flow

它是 GitFlow 的一种更简单的替代方案，将功能驱动开发和功能分支与问题跟踪相结合。

虽然类似于 GitHub Stream分支策略，但主要区别在于添加环境分支（即生产和预生产）或发布分支，还需要综合具体情况。

优点

• 
  

• GitLab 流程比 GitHub 流分支策略更有条理和结构化；

• GitLab 流程可以允许持续交付和版本化发布

• 它适用于小型团队和 Web 应用程序

• 它提供了环境之间的属性隔离，允许开发人员在不同的环境中维护多个版本的软件。

• 如果您的团队主要由高级开发人员组成，这个流程很有效。

• 如果您正在开发最小可行产品，那可能将是完美的。

缺点

• 与初级开发人员一起工作时，应该严格控制他们的工作。

• 这不是最结构化的 Git 分支策略，可能会导致混乱的协作。

• 它的灵活性意味着人们必须仔细定义如何使用它。

• 需要就提议的结构，能够达成良好的沟通和团队协作。

4）Trunk-Based Development（基于主干的开发）

这是一种实际上不需要分支的策略，而是开发人员每天至少一次将他们的更改集成到共享主干中。

这个共享主干可以随时发布。

基于主干的开发是持续集成和扩展持续交付的关键推动力。当团队中的个人每天多次向主干提交更改时，很容易达到持续集成的核心要求，即所有团队成员至少每 24 小时向主干提交一次。这确保了代码库始终可以按需发布，并有助于实现持续交付。

优点

• 随着主干不断更新，为持续集成铺平了道路。

• 开发人员无需创建分支即可查看其他开发人员正在做什么。

• 最适合小型团队。

• 速度非常快，因为开销很小。

缺点

• 团队成熟和经验丰富的开发人员是采用这种方法的必要条件。

• 团队必须非常熟练并谨慎，因为一切都直接进入生产环境；

• 通常，它需要功能标志来帮助将部署代码与发布环境分离。

• 这种策略无法同时支持生产中的多个版本代码。

4）Scaled TDD（规模化基于主干的开发）

为了达到大规模操作，此分支模型使用生命周期为几天（最长）的短期功能分支，然后合并到可随时部署的主干中。

正在进行的工作应保持在最低限度，不仅是为了避免将问题与长期存在的功能分支合并，而且还可以做到更容易和更快的代码审查。

代码审查将保证仅将高质量代码合并到主干中，并允许尽量早地检测缺陷。

优点

• 解决了基于主干策略的诸多问题。

• 实践过 GitHub-flow 分支模型的人会觉得很相像。

• 支持并行开发；

• 通过简单的代码审查确保质量。

缺点

• 这种策略无法同时支持生产中的多个版本代码。

• 短期功能分支用于代码审查和构建检查 (CI)，但不用于工单创建或发布。

5）Release Flow（发布流程）

这是一种基于主干的开发方法，它利用主干的分支来处理特定主题，而不是其它持续部署到主干的基于主干的开发。主题的命名约定与常见产品积压中的术语混淆也更少。

由于合并比较困难，因此鼓励工程师尽早提交避免长时间运行的主题分支，这些分支可能会变得老旧并且越来越难以合并回来。

拉取请求用于合并回主分支。在某种程度上讲，它本质是 Scaled Trunk-Based Development 策略的一种变体。它们之间的主要区别在于，在发布流程中，你可以将维护更改发送到发布分支。

优点

• 可通过扩展，与 Scaled Trunk-Base Development 基本相同

• 允许维护多个版本或发行版。

缺点

• 短期功能分支可用于代码审查和构建检查 (CI)，但不能用于工单创建发布；

• 对生产进行更改时，增加了将意外加入到主分支或发布的可能性；

• 添加可维护的发布分支，为开发和 CI/CD 工具增加了新复杂性。

  
  

如何为项目选择最佳分支策略

我们对当前可用策略的预览后，可以得出的结论是，没有一颗灵丹妙药可以处理任何项目。

以下这张表可能可以帮助我们做出最适合的决定：

参考

• Git 分支策略回顾https://www.learncsdesign.com/a-review-of-git-branching-strategies/

• 一个成功的 Git 分支模型https://nvie.com/posts/a-successful-git-branching-model/

• 什么是最好的 Git 分支策略https://www.flagship.io/git-branching-strategies/

• 最好的 Git 分支策略是什么？https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy

• Git 分支策略，解释https://rewind.com/blog/git-branching-strategies-explained/

• GitHub Flow：使用 Git 和 GitHub 的最佳方式https://githubflow.github.io/

• Git(Hub) 流、基于主干的开发和代码审查https://reviewpad.com/blog/github-flow-trunk-based-development-and-code-reviews/

• GitLab Flow 简介https://docs.gitlab.com/ee/topics/gitlab_flow.html

• 基于主干的开发：简介https://trunkbaseddevelopment.com/

• 功能标志：它们是什么以及如何使用它们https://www.flagship.io/feature-flags/

• 基于主干的开发https://www.flagship.io/glossary/trunk-based-development/

• 发布流程：我们如何在 VSTS 团队中进行分支https://devblogs.microsoft.com/devops/release-flow-how-we-do-branching-on-the-vsts-team/

• 采用 Git 分支策略https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops

作者：韩陆