你真的会写 git commit message 吗？

作者：明明如月学长， CSDN 博客专家，蚂蚁集团高级 Java 工程师，《性能优化方法论》作者、《解锁大厂思维：剖析《阿里巴巴Java开发手册》》、《再学经典：《EffectiveJava》独家解析》专栏作者。

热门文章推荐：

• （1）《人工智能时代，软件工程师们将会被取代？》
• （2）《如何写出高质量的文章：从战略到战术》
• （3）《我的技术学习方法论》
• （4）《什么？ 你还没用过 Cursor？ 智能 AI 代码生成工具 Cursor 安装和使用介绍》
• （5）《我的性能方法论》
• （6）《New Bing 编程提效实践 - 语言识别功能》

一、背景

技术群里有朋友问了一个比较常见的问题：“提交代码的时候描述有什么规定嘛”？
对于这个问题，相信大多数人都认为 too simple。
描述一下这次改了什么内容不就好了吗？

那么怎么描述？能否具体一些？
本文将会给出自己的建议，希望对大家有帮助。

二、建议

2.1 写 message 的目的

• git 的提交信息是用来记录你对代码库的修改的原因和内容的。它可以帮助你和其他开发者追踪代码的变化历史，以及每个变化的作者和时间。
• git 的提交信息可以让你有意识地构建你的代码历史，以便于回溯和审查。你可以在不同的分支上进行提交，并指定你想要包含的修改。提交信息还可以让你利用 git 的一些工具，比如 git log，来方便地浏览和搜索你的提交历史。
• git 的提交信息应该遵循一定的规范和格式，以便于阅读和理解。一般来说，一个好的提交信息应该包括一个类型（比如 feat, fix, docs 等），一个可选的范围（比如 player, login 等），一个简洁明了的描述，以及一个可选的正文和页脚（比如包含更多细节或引用其他资源）。

2.2 写给谁看？

以终为始，提交的 message 给谁看？在什么时候看？

• 通常我们会在阅读代码时，发现这段代码有些困惑，不清楚是干啥的，就会看提交描述来帮助理解。
• 通常我们发现某段代码有 BUG，需要找人背锅的时候，需要看下提交信息。
• 通常我们代码审查的时候会去看该同学有几次提交，分别是实现什么功能。

2.3 怎么写？

commit 的 message 就是描述这次提交干了什么，方便别人阅读和代码审查时了解相关背景。
不要写太含糊的描述，如“修复了3个BUG”、“优化了2个接口”，应该是具体的描述。
通常就写新增什么功能；优化了功能；修复了什么问题；删除了什么等。

2.3.1 建议的格式

feat: 新功能（feature）
fix: 修复 bug
docs: 文档更新
style: 代码格式更新，比如缩进、空格等，不涉及功能修改
refactor: 重构代码，不涉及功能修改
test: 增加或修改测试代码
chore: 构建或辅助工具的变动，比如版本号、依赖更新等
等。

2.3.2 具体示例

feat: 新功能（feature）
git commit -m “feat: 实现 AVOD 内容轮播”
git commit -m “feat: 添加登录页面”

fix: 修复 bug
git commit -am “fix: 修复主页的路由问题”
git commit -m “fix (player): 修复播放器初始化”

docs: 文档更新
git commit -m “docs: 更新 README.md，添加安装说明”
git commit -m “docs: 将 Git 速查表翻译成德语”

style: 代码格式更新，比如缩进、空格等，不涉及功能修改
git commit -m “style: 使用 prettier 格式化代码”
git commit -m “style: 删除尾随空格”

refactor: 重构代码，不涉及功能修改
git commit -m “refactor: 将通用逻辑提取为辅助函数”
git commit -m “refactor: 重命名变量以提高清晰度”

test: 增加或修改测试代码
git commit -m “test: 为用户服务添加单元测试”
git commit -m “test: 修复用户下单集成测试的失败”

chore: 构建或辅助工具的变动，比如版本号、依赖更新等
git commit -m “chore: 将版本号提升到 1.0.0”
git commit -m “chore: 更新依赖项”

三、总结

大家理解写 commit 的 message 目的，就更容易写出更规范的提交信息。
以上格式仅供参考，希望对大家有帮助。

---

创作不易，如果本文对你有帮助，欢迎点赞、收藏加关注，你的支持和鼓励，是我创作的最大动力。