史上最全分支管理模型总结（GitLab Flow）

GitLab Flow是指利用GitLab工具平台来帮助团队更有效地协作和管理软件项目而采用的一种通用开发流程。GitLab Flow的核心思想是建立在Git分支模型及管理实践的基础上，结合GitLab的功能，以实现团队协同开发、自动化测试和持续集成和持续部署（CI/CD）。其目标是提供一种简化、可伸缩和可维护的开发流程，以便团队可以更频繁地交付高质量的软件。它强调了代码审查、自动化测试和持续集成，以确保代码的稳定性和可靠性。这个流程适用于不同规模的项目和团队，并与GitLab平台的功能紧密集成，使其易于使用。下面的分支模型是基于GitLab官网上关于GitLab Flow的系列文章整理，详情请参见附件链接。

分支模型

• 主分支 (main/master): 主分支用于最新稳定版本、问题解决，常驻分支，进行严格代码评审（MR）和自动化测试。

• 特性分支 (feature/描述性名称): 特性分支用于新功能开发，临时分支，从主分支拉出，完成后合并回主分支并删除。

• 环境分支 (如 staging, test, pre-prod): 用于发布前的准备，对应具体的发布环境，从主分支拉出，合并回主分支后删除。

• 版本分支 (如 v1.1/v2.0): 版本分支用于维护特定版本，从主分支特定点拉出，常驻分支。

主要概念

• 主分支（main或master）：通常用于存放可发布、部署的稳定版本代码，在GitLab Flow中，主分支是生产代码的来源。

• 特性分支（Feature branches）：特性分支用于开发新功能、修复缺陷或进行其他工作，每个特性分支通常对应一个特定的功能或任务。

• 合并请求（Merge Requests）：合并请求是一种机制，用于请求将特性分支的更改合并到主分支中，允许团队进行代码审查、测试和讨论。

• 自动化持续集成和持续部署（CI/CD）：一旦合并请求被接受，代码将自动通过CI/CD流水线进行测试和部署，确保高质量的交付。

• 部署到生产环境：特性分支的更改通过测试和审查后，团队可以将它们部署到生产环境中，使新功能或修复缺陷可供最终用户使用。

• 循环：整个过程是循环进行的，每次需要添加新功能或修复缺陷时都会创建新的特性分支并重复上述步骤。

流程模型

GitLab建议的交付流程分为外部、内部反馈循环，以下基于GitLab的流程模型定义从交付流程、分支管理两个角度进行总结。

功能交付流程

1. 规划和需求收集：基于客户反馈和市场分析，确定新功能或改进点，并规划Epic，里程碑点（Milestones），拆解任务并确定优先级（Issues），分配任务（Assign Issue）等。

2. 功能开发：在Feature分支上开发新功能或改进，开发完成后创建MR并提交代码。

3. 内部反馈循环：从提交代码开始，进入被Gitlab Flow定义为『内部反馈循环』的过程：

   • 评审循环：从提交开始进入内部反馈循环，包括自动测试（Automated Test）、静态扫描（Scan）之后，针对合并请求（MR）的功能进行严格的代码评审（Collaboration and review），MR的提交者根据审查意见修订并提交代码（Push Fixes）。

   • 持续审查：代码评审通过后，代码还不能直接合入到主分支，在合入到主分支前需要经过在Gitlab Flow下称为持续审查（Continuous Review）的过程，包括针对被审查的功能建立审查环境并将功能代码（此时称为中间应用）部署到其中，并在审查环境中进行测试（Review App）。

   • 代码合入：MR作者需要根据审查过程中的持续修订问题，一旦功能通过审查和测试，合并请求（MR）变为Merge Accepted状态，代码请求会被合并到主分支，并触发将应用部署到生产环境。

4. 部署和监控：从主分支部署到生产环境，并监控其性能和用户反馈。

5. 收集反馈：收集用户和市场的反馈，用于未来的迭代。

分支管理流程

Gitlab Flow下的分支模型相对于Git Flow/GitHub Flow无论从模型数量、合并操作的复杂度上都有很大的差别，这也就意味着采用GitLab Flow的团队需要进一步约定团队的开发流程。但是GitLab模型的灵活性（也可以说是不完备）同样也导致在这套模型下无法给出精确的分支管理流程模型，类似Git Flow的相对严格的流程。

不过Gitlab Flow的核心特点就是分支与环境的绑定，我们可以通过下面的示意图简单了解下这个模型的思想。

为了弥补分支模型简化所带来的不确定性，Gitlab给出了在此流程模型下的11个最佳实践。

最佳实践

以下是GitLab在其官网给出的，建议遵循的十一个最佳实践：

1. 使用特性（feature）分支而不是直接在主分支（main/master）上进行提交。

2. 测试所有的提交，而不仅仅是主分支上的提交。

3. 对每个提交运行所有测试（如果测试运行时间超过5分钟，可以并行运行）。

4. 在将代码合并到主分支之前进行Code Review。

5. 部署是基于分支或标签的自动化。

6. 标签由用户手动设置，而不是由持续集成（CI）自动设置。

7. 基于标签发布。

8. 已经推送的提交应该从不进行rebase。

9. 始于主分支（main/master），止于主分支。

10. 首先在主分支中修复bug，然后在发布分支中修复。

11. 提交消息应该反映出意图。

适用场景

• 持续集成/持续部署项目：对于采用CI/CD实践的项目，GitLab Flow提供了与自动化构建和部署流程紧密集成的工作流程。

• 多环境部署：适用于需要管理多个部署环境（如测试、预发布、生产环境）的项目，尤其是SaaS平台，因为SaaS平台通常需要在不同的版本发布后维持一段时间的灰度和试验，环境分支策略可以有效解决此问题。

• 需要高度协作的团队：合并请求的审查流程促进了代码质量和团队之间的沟通，适合需要紧密协作的开发团队。

• 寻求简化分支管理的项目：对于希望简化分支结构，减少管理开销同时保持开发流程灵活性的项目和团队。

参考资料

1. What Is GitLab Flow（https://about.gitlab.com/blog/2020/03/05/what-is-gitlab-flow/）

2. What Are GitLab Flow Best Practices（https://about.gitlab.com/topics/version-control/what-are-gitlab-flow-best-practices/）

3. GitLab Flow Duo（https://about.gitlab.com/blog/2023/07/27/gitlab-flow-duo/）