1. 这篇文章解决什么问题commit message看起来只是提交时顺手写的一句话但它会直接影响后续维护体验。糟糕的提交信息通常长这样update fix 修改 wip final当项目过一段时间再回头看就很难知道这次提交到底改了什么 为什么要这么改 影响范围在哪里 能不能安全回退这篇只讲提交信息怎么写得清楚一点。2. commit message 的作用提交信息不是给 Git 看的Git 只关心提交对象和文件快照。提交信息主要是给人看的给未来的自己看 给队友 code review 时看 给排查 bug 时看 给生成 changelog 时看 给回退提交时看一个好的 commit message 至少应该回答这次提交做了什么 属于哪类改动 影响哪个模块3. 推荐格式个人项目里可以使用一个简化版格式type(scope): summary例如feat(redis): add RESP array parser fix(http): handle keep-alive timeout docs(git): add rollback note refactor(net): simplify event loop cleanup三个部分分别是type 改动类型 scope 影响范围 summary 简短说明如果项目很小scope可以省略fix: handle empty request body4. 常见 type 怎么选常用类型feat 新功能 fix 修复 bug docs 文档修改 style 代码格式不影响逻辑 refactor 重构不新增功能也不修 bug test 测试相关 chore 构建、脚本、依赖、杂项维护 perf 性能优化 build 构建系统相关 ci CI 配置相关不用一开始就追求非常复杂的规范。对个人 C 后端项目来说最常用的通常是feat fix docs refactor test chore5. scope 写什么scope表示影响范围。可以写模块名feat(parser): add bulk string parser fix(server): close fd on accept failure也可以写目录或主题docs(git): add conflict resolution note chore(cmake): enable warningsC 后端项目里常见 scopenet http redis parser storage thread cmake test docs gitscope不需要特别精确但应该让人一眼知道这次提交主要影响哪里。6. summary 怎么写summary是一句短说明。推荐习惯使用动词开头 说明这次提交做了什么 不要写太空泛的话比较好的例子fix(http): reject malformed request line feat(redis): support integer reply encoding docs(git): explain reset and revert不太好的例子fix bug update code change files work in progress原因是后者没有告诉别人到底改了什么。7. 一次 commit 应该多大一个实用判断是一次 commit 只做一件完整的事例如这些可以分开1. 新增一个 RESP parser 2. 给 parser 添加测试 3. 调整 README 文档 4. 格式化旧代码不推荐一个 commit 同时包含修 bug 改 CMake 重命名目录 格式化全项目 顺手改 README这样的提交以后很难 review也很难回退。8. 提交前先检查什么提交前推荐固定流程gitstatusgitdiffgitdiff--cached然后再提交gitaddsrc/parser.cpp tests/parser_test.cppgitcommit-mfeat(parser): support array reply parsing这里不建议总是无脑gitadd.因为它可能把临时文件、调试文件、错误修改一起提交进去。9. 多行 commit message如果一次提交比较复杂可以使用多行说明gitcommit进入编辑器后写fix(http): close connection on parse failure The previous code kept the socket open after a malformed request. This could leave idle connections in the event loop longer than needed. Also add a regression test for an invalid request line.第一行是摘要。空一行后写更详细的说明为什么改 怎么改 有什么影响个人学习项目不一定每次都写多行但复杂提交值得写清楚。10. amend 最近一次提交信息如果刚提交完发现 message 写错了gitcommit--amend-mdocs(git): add commit message guide如果需要打开编辑器修改gitcommit--amend注意amend 会生成新的 commit hash 如果已经 push 到共享分支不要随便 amend这一点和06里的回退逻辑一致。11. 常见提交信息示例文档gitcommit-mdocs(git): add gitignore note新增功能gitcommit-mfeat(redis): parse simple string reply修 buggitcommit-mfix(net): handle epoll wait interruption重构gitcommit-mrefactor(server): split request parsing logic测试gitcommit-mtest(parser): cover invalid bulk string构建维护gitcommit-mchore(cmake): enable compile warnings12. 不要把提交信息写成流水账不推荐modify parser and add some files更推荐feat(parser): support RESP bulk string不推荐fix更推荐fix(server): avoid double close on client fd提交信息不需要很长但要有信息量。13. 一句话总结好的 commit message 应该让人不用打开 diff也能大致知道这次提交的类型、范围和目的。个人项目可以先坚持type(scope): summary再配合“小而完整”的提交习惯后续看历史会轻松很多。