将 脚本之家 设为“星标⭐”
来源 | 苏三说技术 （ID：susanSayJava）前言
最近有球友问：三哥，有没有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分支上进行。
核心流程：
GitHub Flow的核心流程图：
适用场景：持续交付、快速迭代的项目。Google内部大量采用类似策略。
2.3 Trunk-Based Development
Trunk-Based Development（主干开发）是Google等大厂推崇的策略。
核心理念：所有开发者都在主干（trunk/main）上工作，通过短生命周期的feature分支进行变更。
关键规则：
- 通过Feature Toggle（功能开关） 控制未完成的功能
Trunk-Based Development的核心流程图：
适用场景：需要极速迭代的互联网产品、DevOps成熟度高的团队。
2.4 三种模型怎么选？
大厂的实际做法往往是
混合模型。
Google内部使用Trunk-Based，阿里使用类似Git Flow的模型但做了简化，腾讯则推荐结合自身情况定制。
有些小伙伴可能会说：“我们团队就五个人，用Git Flow是不是太重了？”
完全可以用简化版。
只保留master和develop两条长期分支，feature分支从develop拉，hotfix分支从master拉。
去掉release分支，用tag代替。
这套“轻量版Git Flow”在很多中小团队里跑得很顺。
三、分支命名规范
大厂对分支命名有严格要求。
一个清晰的分支名应该让人一眼就知道这个分支是干什么的。
3.1 核心命名规则
腾讯云推荐的分支命名格式：
/
常用分支前缀：
| | |
|---|
feature/ | | feature/user-login |
bugfix/ | | 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>():
type（必填） ：描述本次提交的改动类型：
| | |
|---|
feat | | feat(user): 添加用户登录功能 |
fix | | 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）
完整示例：
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：
5.3 PR模板
大厂通常会提供标准化的PR模板，确保每次代码审查都有足够的信息：
## 变更描述
## 关联Issue
- #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）
不符合规范或存在语法错误的代码，无法通过pre-commit检查，也就无法提交。
6.4 CI/CD质量门禁
大厂的CI/CD流水线通常设置了多层质量门禁：
任何一道门禁没通过，代码就无法合并到主分支。
七、Tag管理：版本发布的“里程碑”
大厂对版本发布有严格的Tag管理规范。
7.1 语义化版本（Semantic Versioning）
版本号遵循语义化版本规范：
主版本号.次版本号.修订号
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
