一、背景
技术群里有朋友问了一个比较常见的问题：“提交代码的时候描述有什么规定嘛”？ 对于这个问题，相信大多数人都认为 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 目的，就更容易写出更规范的提交信息。 以上格式仅供参考，希望对大家有帮助。
