本文来自：
万金 极狐 (GitLab) 解决方案专家
杨周 极狐 (GitLab) 高级解决方案架构师
极狐(GitLab) 市场部内容团队
咱们提到的 Workflow 是指什么？
咱们在日常开发工作中提到的 Workflow 通常是指通过 Git（版本控制工具）实现的分布式版本控制（distributed revision control），它容许多名软件开发者，在不同的网络环境下，参加同一个软件开发我的项目。
这种工作模式，比集中式版本控制具备分布式的个性与增量版本的显著劣势，曾经成为行业内支流版本治理办法。
Git 除了最根本的推拉代码，还包含分支、tag、commit，其背地有很多最佳实际，例如：
- 基于哪个分支派生出新分支？合并到哪里去？
- 如何进行代码评审？
- 应用快进、压缩还是间接合并？
- 什么阶段，在哪个分支上创立 tag？
- 怎么设置 Git commit 的格局标准？
这些最佳实际的汇合被称为 工作流（Workflow）。
Git 在 2005 年诞生，最后目标是为了更好地治理 Linux 内核开发而设计。Git 最后只是作为一个能够被其余前端包装的后端利用而开发的，但起初 Git 内核曾经成熟到能够独立地进行版本控制。
仅有版本控制性能还不足以胜任代码托管工作，随后一款基于 Git 的在线源代码托管服务平台 GitHub 于 2008 年 2 月上线。
随着 2007 年继续集成（Continuous Integration）和 2009 年 DevOps 概念的风行，一站式 DevOps 研发平台 GitLab 于 2011 年诞生。
支流 Workflow 有哪些？
近年来，Workflow 基于各类平台疾速倒退。
用于 Linux 的内核版本管理工具 Git 举荐的工作流是 Git flow，源代码托管平台 GitHub 举荐的是 GitHub flow，而 DevOps 研发平台 GitLab 的，则是 GitLab flow。
以上 3 个工作流并不存在好坏之分，只有能够帮忙无效治理并行开发的软件版本、实现团队高效协同的，就是好的 Workflow。每个团队都应该基于不同类型的利用开发场景，抉择最适宜本人的。
点击👉获取一对一咨询服务，抉择适合的 workflow，让研发工作事倍功半~
Git flow
Git flow 面向 多版本长期保护 和多版本同时发 的开发模式，比方框架（Spring 2 和 3 共存）、编程语言（Node.js 18 LTS 和 19 共存）、凋谢 API（v1 和 v2 共存）、多客户定制版。
Git flow 并行开发模式非常复杂，作者自己也在 2020 年发表其「不适宜继续交付」。
并行开发模式如下图：
图 1：Git flow 并行开发分支模型
图中每个分支都有不同的应用场景和用处：
性能分支（Feature）：开发人员以性能名称命名一个分支，独立于其余分支进行开发工作，实现开发后合并入共享开发分支。
共享开发分支（Develop）：用于集成多个性能分支，一个版本全副性能开发实现后，能够拉出公布分支进行公布，而共享开发分支能够持续进行下一个版本的开发工作。
公布分支（Release）：用于保留公布过程中产生的代码批改，公布后会将代码合并到共享开发分支和主分支。
热修复分支（Hotfix）：当某个正式版本呈现紧急 bug 须要修复时，从主分支的对应版本拉出 Hotfix 分支，进行紧急修复，公布后，合并回主分支。
主分支（Master）：用于保留所有公布的版本。
GitHub flow
做为一个代码托管平台的分布式版本治理模型，GitHub flow 绝对简略很多。
其经验过多个版本更迭，V1.0：骨干开发、骨干公布，V2.0：分支开发、骨干公布。作为托管平台，GitHub Flow 对团队约束性较低，难以在团队内造成标准，适宜人数较少的开源我的项目。
图 2：GitHub flow 分支模型（上图为 V1.0，下图为 V2.0）
GitLab flow
作为一站式 DevOps 平台，GitLab 在分布式版本治理的能力与 CI/CD 能力，已有较多欠缺性能，且在并行开发模型和研发治理方面的能力都绝对比拟成熟。
图 3：GitLab 与 GitHub 性能成熟度比拟
在继续集成方面，GitLab 推出了一系列性能保障骨干分支的代码品质：
- 对受爱护分支的批改必须通过审批能力实现代码合并；
- 通过代码扫码和自动化测试保障代码品质的同时引入代码评审，保障公布的每一行代码都是有质量保证的；
- 通过二进制仓库作为 CI 与 CD 的连接点，确保生产环境版本可追溯到对应源代码。
图 4：GitLab CI/CD 模式
GitLab flow 有三种举荐的 flow 模式：
- 环境分支 Environment branches with GitLab flow；
- 产品分支 Production branch with GitLab flow；
-
公布分支 Release branches with GitLab flow。
以环境分支为例：
图 5：环境分支模型
每个分支应用场景如下：
- 主分支 Master：用于性能开发，每次代码合并主分支都有流水线进行品质看护，保障主分支随时能够公布到准生产环境；
- 准生产环境 Pre-Production：用于进行性能与部署办法的测试，只有达到肯定质量标准能力公布到生产环境；
- 生产环境 Production：用于保留公布的软件版本。
仿佛毛病什么不是吗？
对应以上三种支流 flow，根本能够笼罩各类不同复杂度的我的项目。
- 复杂度 4，同时反对多个并行版本的成熟我的项目（Git flow）：其作者文森特·德里森（Vincent Driessen）示意其过于简单，不适宜继续交付场景下应用；
- 复杂度 3，反对 DevOps 实际与办法的多环境继续交付我的项目（GitLab flow）：具备成熟的品质管控性能与继续交付能力；
- 复杂度 1，开源软件的代码托管（GitHub flow）：基于代码托管，模型比较简单，能够疾速交付，但难以造成研发标准。
图 6：支流工作流复杂度比照
但，这全面了吗？
如果我的企业，既须要麻利疾速迭代（如 GitHub Flow），也须要肯定的研发标准、确保安全可控（如 GitLab Flow）呢？
极狐 flow
极狐 GitLab 研发团队依据多年实践经验，推出了 「极狐 flow」（JiHu flow），既简略易上手（对应上图，复杂度为 2），又兼具团队研发规范性， 非常适合在标准保障根底上、强调麻利翻新、疾速迭代的我的项目。
分支模型如下图：
- 共享开发分支（Develop）：用于集成性能分支的代码，因为设置了爱护分支，所以应依据需要创立个性分支，通过自动化流水线进行品质看护，经代码评审后合入共享开发分支，同时默认删除个性分支；
- 主分支（Master）：用于正式版本和热修复版本公布。
图 7：极狐 flow 分支模型
极狐 flow 全景图
- 我的项目打算：通过麻利形式进行我的项目迭代；
- 代码编写：提交规定进行需要与代码的关联，从 Develop 分支创立个性分支保留性能编码，代码更新后触发继续集成，合乎品质要求的代码进入代码评审，缩小品质危险，代码负责人能够保障要害代码批改的品质；
- 开发环境部署：将代码合并到 Develop 分支，主动删除需要分支，通过容器形式进行构建，镜像存入二进制仓库，实现部署后进行集成测试；
- 测试环境部署：将性能代码从 Develop 分支合并至 Master 分支，自动化测试保障性能残缺，通过动静安全检查模仿平安演练，最初进行验收测试；
- 生产环境公布：通过评审触发正式公布过程，所有软件公布的过程，环境配置都存储在代码仓库中，这是 GitLab 特有的 GitOps 实际。
图 8：JiHu flow 全景图
极狐 flow 最佳实际
分支命名标准
正则表达式（如果是小型我的项目，可省略 develop 分支）：
main|develop|(\d+-(feature|bugfix|hotfix)-[A-Za-z0-9]+)分支示例：
master：主分支
develop：共享开发分支
1-feature-sms-deng-lu：需要分支
2-bugfix-sms-repeat：缺点分支
3-hotfix-register-failed：热修分支
其中数字为需要 / 缺点的 ID，所以该当先创立需要 / 缺点，再写代码，杜绝「口头加需要」、「口头报 bug」的状况。通过需要分支和合并申请草稿性能，能够不便地为需要人员创立需要分支，暂存代码批改。
应用极狐 GitLab 创立需要 / 缺点应应用「feature|bugfix|hotfix」结尾，能够一键创立符合规范的分支，开发人员再也不必为分支命名发愁。另外中文需要（issue）可主动转化为拼音分支名，例如：Feature：SMS 登录变为 1-feature-sms-deng-lu。
分支起源与合并
feature 和 bugfix 分支来自 develop，实现开发后应合并到 develop，且在合入后主动删除 feature 和 bugfix 分支，缩小过多的分支数量。
hotfix 分支来自 main，实现开发后应合并到 main，且在合入后主动删除 hotfix 分支。
公布时，将性能代码从 develop 合并到 main，合并后不会删除分支。
如果是小型我的项目，无 develop 分支，则 feature、bugfix 和 hotfix 分支都来自 main，也会合入到 main，合并后主动删除多余分支。
举荐应用快进式（Fast-forward）合并，而不举荐应用惯例合并（产生一条冗余 commit）。
如果 commit 有多条调试记录，则应压缩为一条，不得强制应用压缩。
可通过极狐 GitLab「设置 → 合并申请」进行设置：
爱护分支
所有的公共分支都必须被爱护，包含公共开发分支 develop。
常见谬误：爱护了 master，而未爱护 develop，大家随便提交 develop，最初 develop 合并到 master，导致未经审核的代码进入生产环境。
可通过极狐 GitLab「设置 → 仓库 → 受爱护分支」进行限度：
代码评审
禁止将批改代码间接合入分支，必须通过合并申请，由至多另一位开发者进行代码评审，批准后才可合并。
评审必须在合并之前，合并后、上线后的评审只能称为「技术分享」，而非「代码评审」。
只在长期分支（feature、bugfix、hotfix）合并到公共分支时进行评审，而不评审公共分支的相互合并（比方 develop 合并到 main，单向合并缩小评审工作量）。
可通过极狐 GitLab「设置 → 合并申请 → 合并申请批准」实现代码管控：
业务代码中应应用标准扫描工具和配置文件，必须配置本地钩子 .Git/hooks/pre-commit 执行扫描，进行强制查看代码标准。
如果我的项目配置了继续集成流水线，则应该用和本地统一的代码标准进行查看，继续集成流水线必须胜利，才能够合并，这也是安灯实际的要求。
代码评审提出的评审倡议，须要全副解决，才能够合并。
提交信息标准
Git commit 采纳 Angular 标准，正则表达式：
(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert): #\d+ .+正确示例：
feat: #1 sms 登录
fix: #2 sms repeat
fix: #3 register failed
英文前缀固定，后半局部能够写汉字等多种语言的文字。
其中数字为需要 / 缺点的 ID，所以必须先创立需要 / 缺点，再写代码，杜绝「口头加需要」、「口头报 bug」的状况。
可通过极狐 GitLab「设置 → 仓库 → 推送规定」中，设置正则表达式进行限度：
提交人员身份查看
Git commit 时读取了 Git config user.name 与 user.email，推送到服务器时必须至多校验 email，杜绝「集体邮箱推送到公司我的项目」的状况。
可通过极狐 GitLab「设置 → 仓库 → 推送规定」进行验证：
禁止提交垃圾文件
禁止提交第三方包（比方 jar、node_modules、vendor）、编译打包后果（比方 apk、exe、zip），以及任何大于 4MB 的文件。
倡议应用 .Gitignore 进行配置，或者可通过极狐 GitLab「设置 → 仓库 → 推送规定」进行限度：
tag 与版本号标准
采纳 npm 和语义化标准，版本号不应用 v 前缀，而 Git tag 应用 v 前缀，防止纯数字导致的问题，正则表达式：
v(\d+.){1,2}\d+示例：
v0.1
v1.2.0
v2.0.0
当提取 Git tag 用作 Docker、maven、npm 等版本号时，应在应用时去除 v 前缀，比方：
https://Github.com/nodejs/nod…
docker pull node:19.1.0
maven se.bjurr.violations:violations-maven-plugin:1.50.4
部署
举荐应用 GitOps 进行部署，即：
- 遵循「基础设施即代码」的理念，将 K8s yaml、微服务编排配置文件、Terraform 等文件保留于 Git 中，与业务代码离开；
- 优先应用拉取式部署（无需公网 IP，更平安）而不是推送式部署；
- 借助 Git 的合并申请进行上线审批，记录可追溯。
性能开关
多个需要的代码合并之后，在上线之前可能会遇到一个需要代码有重大问题，来不及修复的状况，或者尚未达到业务部门的公布工夫（发布会、节日促销等）。此问题不应该从 git 角度解决，因为无论是剔除代码，还是需要分支迟迟不合并，两者的老本都比拟高 。此时举荐应用 性能开关（Feature Flags）。
性能开关能够实现 「AB 测试」 和「先部署，后公布」。研发人员提前部署，将产品性能公布的势力，交给业务部门，进步了合作效率。
通过以上 10 个实际，心愿帮忙所有翻新类型的产品进行疾速迭代，而又不用就义规范性与品质。如果是外部应用产品也能够进一步简化分支模型，只应用 master 分支进行性能开发和版本公布即可。
参考文档
https://docs.Gitlab.cn/
https://about.Gitlab.com/why-…
https://forge.etsi.org/rep/he…