如何设计实施 Git 工作流程以提升软件研发效能？

第一步，在建立 Git 流程之前，建议首先选择基于 Git 的代码托管协作平台，并登入现有代码仓库。市面上有诸多免费、付费、SaaS、on-prem 的平台方案，要根据自身的预算情况和协作模式做出选择。后续涉及到一些术语将基于 GitHub/GitHub Enterprise，其他代码托管协作平台大同小异。

在基础设施就绪之后，首先要回答一个大问题：代码协作流程是要求全局统一还是允许不同团队、项目有自己的选择？如果是全局统一，在哪些区域允许受限的灵活度？

第二步，建立基本的协作模式。以 GitHub 为例，大体有 Fork and Pull 与 Branch and Pull 两种模式。前一种模式基于分叉（Fork）仓库，常见于开源社区；后一种模式基于同一仓库的不同 Branch，企业内部更为常见。两种模式各有优劣：Fork 的优势在于对上游源仓库保护较好（无需赋予贡献者写权限），但基于特性分支（Feature Branch）的多人协作开发模式则比较别扭——这里也带来了一个较好的副作用，即开发人员必须频繁同步和合并代码，这是契合持续集成精神的；同时对于自建代码托管协作平台的情景来说，还会增大计算和存储资源的开销。Branch and Pull 模式除了在权限控制上要更为小心之外，长寿的特性分支（Long-lived Feature Branch）也会增大集成和仓库运营的难度（本人曾经清理过堆积了 3000 多特性分支多代码仓库，苦不堪言）。但无论选择何种模式，或因地制宜，都建议采用 Pull Request 的机制来建立代码自动化检查和人工审核的流程。

第三步，建立分支模型。在公开领域能找到的主要有 Git-Flow（https://nvie.com/posts/a-successful-git-branching-model/）、GitHub Flow（https://docs.github.com/en/get-started/quickstart/github-flow#following-github-flow）、Trunk-based Flow（https://trunkbaseddevelopment.com/）等几种，也有不少比较这些模型的文章，这里简单的讲述一下。Git-Flow 可以覆盖各种场景，包括相对传统的企业级应用开发（可能需要同时在多个版本上进行活跃开发或长期维护活动）以及 Web/SaaS 类应用，适用于大型团队多版本（通过发布分支）、多环境的代码管理，但其缺点是规则细、分支多、需要合并代码的场合频繁，会给团队带来不小的认知负荷和管理复杂度；GitHub Flow 在 Git-Flow 的基础上简化为了主干分支和特性分支，适用于小型团队、Web/SaaS 类开发，但几乎无法支持多个版本的代码同时开发；Trunk-based Flow 则是更“极端”的 GitHub Flow，严格要求小步快跑、单个分支，客观上对研发团队的能力提出了更高要求，包括持续集成、持续发布的能力，以及通过功能特性开关（Feature Toggle）来控制代码质量与行为等架构上的能力。

在实际建立模型的时候，要因地制宜，结合自身团队和业务特点，并在需要时更新模型。要谨记的是，分支带来的技术和管理的复杂度不可小视，分支（或同时活跃的分支）越少越好，能用两个活跃分支解决的协作问题就不要用三个；要反复强调持续频繁合并代码的重要性，消灭长寿的特性分支，及时清理已合并分支。分支的滥用背后往往是战术上的勤劳，战略上的懒惰，长此以往甚至会对代码架构产生难以逆转的危害。

第四步，定义 Git Tag 和版本的规则。对于 Git Tag ，同样建议采用业界通用的语义化版本（https://semver.org/lang/zh-CN/）方案。另一方面要考虑产品、项目版本是否直接复用 Git Tag，还是需要固定的文本映射关系，如在 Git Tag 之前或者之后加上特定的描述文字（例如 service@v1.0.1-rc.1）；或者用在更高层面的产品版本号来包含，如 aa.bb.cc.dd（例如 01.01.01.02）或年份（如 2022H2，表示 2022 年下半年的版本）。在这种场景下，需要建立一些简单数据管理系统来确保通过大版本号能追溯到任一组件的 Git Tag 。

第五步，通过 Commit/Pull Request 模板来实现 Git Commit 与需求管理系统的关联。常见的做法是引入 Conventional Commit（https://www.conventionalcommits.org/zh-hans/v1.0.0/），通过限定规则将对应的故事/缺陷号码写在标题或者正文中（确保能简单解析与关联即可），同时在自动化代码检查的任务中对关联的项目进行检查，确保正确的关联。这样便能将代码平台与需求管理系统链接起来。

综上，以 Git 和代码托管协作平台作为软件交付的管理与追踪中心是非常好的实践，在实施过程中务必要建立一套简明标准的数据关联规则，并持续地要求、建立自动化检查机制来确保各个开发团队严格遵守。

本文整理自《研发效能100问》，原作者：管俊 戴尔中国 卓越研发集团 DevOps 架构师