一线大厂的 Git 规范

作者：苏三 · 2026-08-09 · 技术文章

前言

最近有球友问：三哥，有没有好一点的 Git 规范，可以发我参考一下？

今天这篇文章，我就把一线大厂都在用的 Git 规范从头到尾给你拆解一遍。希望对你会有所帮助。

一、为什么大厂如此重视 Git 规范？

在聊具体规范之前，我们先理解一个根本问题——为什么大厂把 Git 规范看得这么重要？

第一个原因：规模。

大厂一个项目可能有几十甚至上百个开发同时在改代码。如果没有规范，分支冲突、代码覆盖、版本混乱这些问题会像雪崩一样压垮团队。

第二个原因：可追溯性。

线上出了 bug，需要快速定位是谁改的、什么时候改的、改了什么。如果 commit message 写得一塌糊涂，排查问题就像大海捞针。

第三个原因：自动化。

大厂的 CI/CD 流水线高度依赖 Git 规范——从 commit message 自动生成 changelog、从分支名自动触发对应环境的部署、从 tag 自动决定版本号。

规范写得好不好，直接决定流水线能不能跑起来。

说白了，规范不是用来"管人"的，是用来"省事"的。

二、大厂都在用什么模型？

分支策略是 Git 规范的"骨架"。目前大厂主流的分支模型有三种：

2.1 Git Flow：最经典的企业级模型

Git Flow 是 2010 年由 Vincent Driessen 提出的分支模型，至今仍是很多大厂的标准实践。

它定义了两种长期分支和三种短期分支。

两种长期分支（永久存在）：

master/main：生产环境分支，存放已发布的稳定版本。禁止直接提交代码。
develop：日常开发主分支，汇总所有正在推进的功能。

三种短期分支：

feature：功能开发分支，从 develop 创建，完成后合并回 develop。
release：发布准备分支，从 develop 创建，测试通过后合并到 master 和 develop。
hotfix：紧急修复分支，从 master 创建，修复完成后合并回 master 和 develop。

Git Flow 的核心流程图：

适用场景：有明确版本发布计划的大型项目、需要同时维护多个版本的软件。

2.2 GitHub Flow：更轻量、更敏捷

GitHub Flow 是 GitHub 官方推荐的工作流，比 Git Flow 简单得多。

核心只有一条长期分支 main，所有开发都在短期 feature 分支上进行。

核心流程：

从 main 创建 feature 分支
在 feature 分支上开发并提交
创建 Pull Request
代码审查通过后合并到 main
合并后立即部署

GitHub Flow 的核心流程图：

适用场景：持续交付、快速迭代的项目。Google 内部大量采用类似策略。

2.3 Trunk-Based Development

Trunk-Based Development（主干开发）是 Google 等大厂推崇的策略。

核心理念：所有开发者都在主干（trunk/main）上工作，通过短生命周期的 feature 分支进行变更。

关键规则：

feature 分支生命周期不超过 1-3 天
保持 main 始终可部署
通过 Feature Toggle（功能开关）控制未完成的功能

Trunk-Based Development 的核心流程图：

适用场景：需要极速迭代的互联网产品、DevOps 成熟度高的团队。

2.4 三种模型怎么选？

对比维度	Git Flow	GitHub Flow	Trunk-Based
复杂度	高	低	中
适合团队规模	大团队	中小团队	任何规模
发布节奏	按版本发布	持续交付	持续交付
热修复	hotfix分支	feature分支	feature分支
多版本维护	✅ 支持	❌ 不支持	⚠️ 有限支持

大厂的实际做法往往是混合模型。

Google 内部使用 Trunk-Based，
阿里使用类似 Git Flow 的模型但做了简化，
腾讯则推荐结合自身情况定制。

有些小伙伴可能会说："我们团队就五个人，用 Git Flow 是不是太重了？"

完全可以用简化版：

只保留 master 和 develop 两条长期分支，feature 分支从 develop 拉，hotfix 分支从 master 拉。
去掉 release 分支，用 tag 代替。

这套"轻量版 Git Flow"在很多中小团队里跑得很顺。

三、分支命名规范

大厂对分支命名有严格要求。一个清晰的分支名应该让人一眼就知道这个分支是干什么的。

3.1 核心命名规则

腾讯云推荐的分支命名格式：

<类型>/<内容>

常用分支前缀：

前缀	用途	示例
feature/	新功能开发	feature/user-login
bugfix/	Bug修复	bugfix/login-timeout
hotfix/	紧急线上修复	hotfix/payment-crash
release/	版本发布准备	release/v2.1.0
chore/	构建/工具变动	chore/update-dependencies

3.2 进阶规范（大厂标配）

大厂通常会在基础命名上增加更多约束：

① 关联工单号

分支名强制包含 JIRA/工单系统的编号：

feature/PROJ-123-user-login
hotfix/PROJ-456-payment-timeout

这样从分支名就能直接追溯到需求或 Bug 单，不用再去翻记录。

② 语义化描述

描述部分要简洁明了，让别人知道这个分支大概改了什么东西：

# ❌ 错误
feature/aaa
feature/test
feature/111

# ✅ 正确
feature/user-authentication
feature/order-payment-refund
hotfix/memory-leak-in-cache

③ 版本号规范

release 和 hotfix 分支要带上版本号：

release/v2.1.0
hotfix/v2.0.1-payment-fix

四、Commit Message 规范

Commit message 是大厂 Git 规范中最容易被忽视、但最重要的环节。

4.1 为什么 Commit Message 如此重要？

大厂之所以对 commit message 如此重视，有三个核心原因：

原因一：代码审查的基础。

好的 commit message 能让 reviewer 快速理解每次改动的目的和范围，大幅提升审查效率。

原因二：自动化生成 Changelog。

规范的 commit message 可以直接被工具解析，自动生成版本发布日志。

原因三：问题追溯的线索。

线上出 bug 时，通过 git blame 看到的是一个清晰的 commit 描述，而不是一句 "fix"。

4.2 Conventional Commits：大厂的标准答案

大厂普遍采用 **Conventional Commits（约定式提交）**规范。格式如下：

<type>(<scope>): <subject>

type（必填）：描述本次提交的改动类型：

type	含义	示例
feat	新增功能	feat(user): 添加用户登录功能
fix	修复bug	fix(api): 修复接口超时问题
docs	文档更新	docs(readme): 更新部署说明
style	代码格式（不影响功能）	style: 统一缩进为4空格
refactor	代码重构	refactor(order): 优化订单查询逻辑
perf	性能优化	perf(cache): 优化缓存命中率
test	测试相关	test(auth): 增加登录单元测试
chore	构建/工具变动	chore: 升级Spring Boot版本

scope（可选）：描述改动的影响范围。比如 feat(user) 中的 user 表示改动涉及用户模块。

subject（必填）：简短描述：

使用一般现在时，不要用过去时（add vs added）
使用祈使句（add feature vs I added feature）
首字母不要大写
句尾不要加句号
不超过 50 个字符

完整示例：

git commit -m "feat(user): 添加用户登录功能"
git commit -m "fix(api): 修复接口超时问题"
git commit -m "docs(readme): 更新项目说明文档"
git commit -m "refactor(order): 拆分订单Service类"

4.3 长篇 Commit Message

如果需要详细说明，可以写多行：

fix(payment): 修复支付回调超时问题

问题原因：第三方支付接口响应时间不稳定，超过30秒超时阈值

解决方案：
- 将超时时间从30秒调整为60秒
- 增加重试机制（最多3次）
- 添加降级方案，超时后记录异常并返回处理中状态

影响范围：PaymentService.handleCallback方法
测试情况：已通过单元测试和集成测试

4.4 几个核心原则

**原则一：每个提交解决一个或一类问题。**不要把多个不相关的改动塞进一个 commit。

**原则二：提交的代码量不宜过大。**建议单次提交不超过 300 行。大厂一般要求每个 PR 不超过 500-800 行。

**原则三：提交前确保代码已通过自测。**不要提交"应该能跑"的代码。

五、代码审查（Code Review）

分支策略和 commit 规范解决的是"怎么写"的问题，Code Review 解决的是"怎么保证质量"的问题。

5.1 为什么要做 Code Review？

大厂对 Code Review 的重视程度，远超大多数人的想象。

Code Review 的核心价值有三点：

价值一：提前发现 bug。

测试能发现的问题，Code Review 能发现；测试发现不了的问题（如设计缺陷、性能隐患），Code Review 也能发现。

价值二：知识传递。

新人通过 review 老员工的代码，能快速了解项目规范和最佳实践。

价值三：统一代码风格。

多人协作最怕风格不统一，Code Review 是强制执行风格规范的最后一道防线。

5.2 分支保护规则

大厂通过分支保护规则来强制 Code Review：

禁止直接 push 到 main/master 分支
合并前必须通过 Code Review
合并前必须通过 CI 自动化检查
至少 2 名审批人同意（核心项目甚至要求 3 人）

5.3 PR 模板

大厂通常会提供标准化的 PR 模板，确保每次代码审查都有足够的信息：

## 变更描述
<!-- 简要描述本次改动的内容 -->

## 关联Issue
<!-- 关联的JIRA/工单编号 -->
- #12345

## 改动内容
- [ ] 修改了登录逻辑
- [ ] 添加了单元测试
- [ ] 更新了相关文档

## 测试情况
- [ ] 本地已自测通过
- [ ] 单元测试覆盖率 ≥ 80%
- [ ] 集成测试通过

## Checklist
- [ ] 代码符合项目风格规范
- [ ] 没有引入不必要的依赖
- [ ] 没有破坏现有功能
- [ ] 敏感信息（密码/密钥）没有提交

5.4 审查清单

PR 审查者应该检查哪些内容：

代码是否符合项目风格指南
测试覆盖率是否达标（大厂一般要求 ≥80%）
是否引入了不必要的依赖
文档是否已更新
是否会破坏现有功能

六、自动化工具链

有些小伙伴可能会说："规范写好了，但团队不执行怎么办？"

大厂的解决方案是：用工具强制落地，而不是靠自觉。

6.1 Commit Message 校验（Commitlint）

通过 Commitlint + Husky 在 git commit 时自动校验 commit message 格式。

配置示例：

// commitlint.config.js
module.exports = {
    extends: ['@commitlint/config-conventional'],
    rules: {
        'type-enum': [2, 'always', [
            'feat', 'fix', 'docs', 'style', 'refactor', 
            'perf', 'test', 'chore', 'revert'
        ]],
        'subject-max-length': [2, 'always', 50],
        'body-max-line-length': [2, 'always', 72]
    }
};

配合 Husky 在 commit-msg 钩子中执行校验：

// .husky/commit-msg
#!/bin/sh
npx --no -- commitlint --edit $1

不符合规范的 commit 会被直接拒绝，无法提交。

6.2 分支命名校验

通过 Git hooks 或 CI 工具校验分支命名是否符合规范。

阿里云提供了仓库规范设置功能，可以强制限制分支命名规则和合并方向。

校验逻辑示例：

# 检查分支名是否符合规范
branch_name=$(git symbolic-ref --short HEAD)
if [[ ! $branch_name =~ ^(feature|bugfix|hotfix|release|chore)/ ]]; then
    echo "❌ 分支命名不符合规范，请使用 feature/、bugfix/、hotfix/、release/ 或 chore/ 前缀"
    exit 1
fi

6.3 Pre-commit 代码检查

在代码提交前自动执行格式化和静态检查：

pre-commit：代码格式化（Prettier/Black）
静态检查：ESLint/Checkstyle
类型检查：TypeScript/mypy

不符合规范或存在语法错误的代码，无法通过 pre-commit 检查，也就无法提交。

6.4 CI/CD 质量门禁

大厂的 CI/CD 流水线通常设置了多层质量门禁：

编译门禁：代码必须能成功编译
测试门禁：单元测试必须全部通过，覆盖率≥80%
Lint 门禁：代码风格检查必须通过
安全扫描门禁：不能存在高危漏洞

任何一道门禁没通过，代码就无法合并到主分支。

七、Tag 管理：版本发布的"里程碑"

大厂对版本发布有严格的 Tag 管理规范。

7.1 语义化版本（Semantic Versioning）

版本号遵循语义化版本规范：

主版本号.次版本号.修订号

主版本号：不兼容的 API 变更
次版本号：向下兼容的功能性新增
修订号：向下兼容的问题修复

7.2 Tag 创建与推送

# 创建带注释的Tag
git tag -a v2.1.0 -m "Release version 2.1.0"

# 推送Tag到远程
git push origin v2.1.0

# 推送所有Tag
git push origin --tags

八、核心流程全景图

把上面所有规范串起来，一个完整的 Git 工作流应该是这样的：

九、优缺点总结

Git 规范的优点

1. 团队协作效率大幅提升

分支命名清晰、commit message 规范，团队成员之间不需要额外沟通就能理解彼此的改动。

2. 代码质量有保障

Code Review + CI 门禁的双重保障，让有问题的代码很难合入主分支。

3. 问题追溯快速准确

规范的 commit message 配合 git blame，线上出 bug 能快速定位到具体的改动和作者。

4. 自动化程度高

规范的 commit message 可以直接用于自动生成 changelog、自动决定版本号，大幅减少人工操作。

5. 新人上手快

统一的规范让新人能快速理解项目的开发流程和代码演进历史。

缺点

1. 规范需要工具支撑

没有工具强制落地，规范就是一张废纸。需要配合 Commitlint、Husky、CI 门禁等工具。

2. 初期有适应成本

团队从"自由模式"切换到"规范模式"，前几周会有一些不适应和抵触情绪。

3. 需要持续维护

规范不是写一次就完了，需要根据团队规模和业务变化持续调整。

4. 不要过度设计

规范的目的是"省事"，不是为了"管人"。过于复杂的规范反而会降低开发效率。

十、写在最后

回到最初的问题：为什么大厂如此重视 Git 规范？

因为当团队从几个人扩张到几百人时，混乱带来的成本会以指数级增长。

一个分支命名不规范，可能就导致一次部署事故；
一个 commit message 写得不清不楚，可能就让排查线上问题多花两个小时；
一次没有经过 Code Review 的合入，可能就把一个 bug 带进了生产环境。

规范不是为了约束你，而是为了保护你。

Git 规范的价值不在于它"多好看"，而在于它能让几百人在同一个代码库里高效协作、互不干扰。

如果你现在才开始重视 Git 规范，建议从三件事做起：

**第一步：统一 commit message 格式。**这是投入产出比最高的优化——用 Conventional Commits 规范，配合 Commitlint 强制校验。

**第二步：建立分支模型。**哪怕是简化版——master 线上、develop 开发、feature/* 功能开发。

**第三步：开启 Code Review。**从"所有合入都看一眼"开始，慢慢养成习惯。

这三件事做下来，你团队的代码质量和协作效率，会有肉眼可见的提升。

好的习惯，是团队协作最好的润滑剂。

十一、参考资源

Conventional Commits 规范：https://www.conventionalcommits.org
Commitlint：https://commitlint.js.org
Git Flow：https://nvie.com/posts/a-successful-git-branching-model
阿里 Git 规约：https://alibaba.github.io/f2e-spec/zh/engineering/git