17611538698
webmaster@21cto.com

2022 Git 分支策略最佳实践

运维 0 889 2022-09-23 10:48:12

图片

概述

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

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

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

图片

关于 Git 分支


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

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

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

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

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

为什么需要分支策略

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

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

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

  • 启用并行性开发;

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

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

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


有哪些常见的分支策略

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

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

1) GitFlow


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

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

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

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

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

图片

来源:https ://nvie.com/img/git-model@2x.png


优点


  • 保护生产代码;

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

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

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

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


缺点

  • 开发周期可能会减慢;

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

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

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


2)GitHub stream

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

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

图片

来源:https ://reviewpad.com/wp-content/uploads/2021/06/GitHub-Flow.svg


优点

  • 最简单的策略之一;

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

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


缺点


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

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

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

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

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

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


3)GitLab Flow


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

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

图片

来源:https ://qiita.com/tlta-bkhn/items/f2950aaf00bfb6a8c30d


优点


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

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

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

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

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

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


缺点

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

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

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

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


4)Trunk-Based Development(基于主干的开发)

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

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

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

图片

来源:https ://trunkbaseddevelopment.com/trunk1b.png


优点

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

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

  • 最适合小型团队。

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


缺点

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

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

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

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


4)Scaled TDD(规模化基于主干的开发)


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

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

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

来源:https ://trunkbaseddevelopment.com/trunk1c.png


优点

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

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

  • 支持并行开发;

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


缺点

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

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


5)Release Flow(发布流程)

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

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

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


来源:
https ://devblogs.microsoft.com/devops/wp-content/uploads/sites/6/2018/04/branchstrategy-cherrypick1.png


优点

  • 可通过扩展,与 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


作者:韩陆


评论