云原生技术：Git到底该建多少个分支？ _Git

目前世界上大部分公司都使用Git来控制软件开发的版本，那么我们用Git到底该建多少个分支呢？2010年Vincent Driessen在《A successful Git branching model》一文中提出了一个GitFlow的工作流程模型。

文章插图

核心分支
在GitFlow方案中，最核心的分支有两个：主分支（Master）分支和开发（Develop）分支。当Develop分支的源码到达了一个可以发布的稳定状态时，所有的代码变更需要合并到Master分支上，然后标记一个版本号。

文章插图
Master分支和Develop分支
除了核心分支，GitFlow模型还提出了几种辅助性分支，包括功能（Feature）分支、发布（Release）分支、热修复（HotFix）分支。

文章插图
Feature分支要合并到Develop分支
功能分支是为将来要发布的版本开发新的功能，只要这个功能处于开发状态，这个分支就会存在，最终会合并到Develop分支，或者被取消（比如产品经理改变了主意）。

文章插图
Release分支从Develop分支创建，最终合并到Develop分支和Master分支
Release分支是从Develop分支创建，是为新产品的发布做准备的，将即将发布的功能打包在这个分支。打完Release分支之后，可以在这个Release分支上测试及修改Bug 。最后Release分支要合并到Develop和Master分支上。

文章插图
Hotfix分支从Master分支创建，再合并到Master分支和Develop分支
热修复分支基于Master分支创建，一般用于线上bug的紧急修复。开发完后需要合并回Master和Develop分支。
不过GitFlow这个模型已经提出了10多年，当时的软件开发环境和现在大不相同，Vincent Driessen也意识到了这一点，在2020年他说世界上没有万能药存在，无论选择哪种流程，需要考虑自己的情况。

If, however, you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild, then git-flow may still be as good of a fit to your team as it has been to people in the last 10 years. In that case, please read on.
To conclude, always remember that panaceas don't exist. Consider your own context. Don't be hating. Decide for yourself.
Vincent Driessen，March 5, 2020.

GitFlow模型相对比较复杂，比较适合需要同时维护多个版本的情况，不太适用于现在的互联网开发。Github Flow流程就非常简单。

文章插图
Github Flow
我自己团队的情况是这样的：除了开发环境以外，还有测试环境、预生产环境和生产环境。Develop分支对应的是测试环境，Release分支对应的是预生产环境，Master分支对应的是生产环境。Release分支的代码基本不会修改，主要是为了触发在预生产环境的自动化部署流程而设的。
我们正常的发布流程是：测试环境 -> 预生产环境 -> 生产环境。如果遇到线上紧急问题需要修复，那么就从Master分支上拉下代码紧急修复，线上问题处理好了，再合并到Develop分支上，相当于GitFlow模型中的HotFix分支。
总之，无论选择怎样的Git流程，适合自己的才是最好的。
我会持续更新关于物联网、云原生以及数字科技方面的文章，用简单的语言描述复杂的技术，也会偶尔发表一下对IT产业的看法，欢迎大家关注，谢谢。