- Connor2026-07-19
看同事的提交记录：“fix bug”、“update”、“aaa”、“终于好了”、“不知道改了啥”、“再试一次”。再看人家的开源项目的：“feat: add xxx module”、“refactor: optimize database queryxxxx”。差距感扑面而来。我每次想写正经的commit message，脑子里就可以左右互搏！！！最后打了一个":wq"完事。有没有人跟我一样，git commit -m 后面的内容永远是最纠结的一步呀。 ^-^ ^-^
主楼 - Z-linuxdo2026-07-19
乱写git记录平时没啥问题，等一出bug需要回滚的时候有你受的 ^-^
- 洛卡卡了2026-07-19
如果是开源的项目，最好是按照标准写就行。如果是自己的项目 就随便了。如果是公司的项目，一般公司负责人都会有固定的标准的 但是一般是主仓库，辅助仓库一般没有太大的严格标准。
- yoyoyo2026-07-19
这次提交改动了啥就写啥，改了哪个业务点啥的，增加了啥功能之类的
- Enze2026-07-19
- apparition2026-07-19
- busytime2026-07-19
bugfix/codefix/test/commit
- coconut2026-07-19
- Listky2026-07-19
现在我们项目组用的插件，git comiit template，这种生成出来的格式比较统一了
- gamecrafters2026-07-19
AI生成看一眼就行，大部分时间不需要自己写
- 归谜2026-07-19
直接交给 caveman-commit 根据 diff 生成，后续自己再在基础上补充业务注释。
- 绿叶菜2026-07-19
一般在vscode里面敲一个 feat、fix、chore之类的，copilot就会自动帮你补全了
- Exception2026-07-19
fix XXX，feature XXX，optimize XXX，hotfix XXX。要写成自己看了能记住是因为啥改的就可以了
- Mengzhisha2026-07-19
更新日志: 修复了一些已知问题。
- 暖冬2026-07-19
只能说明不知道修改了啥，开发了啥才会迷糊吧。通常建议一次提交做好一个功能比较好。记录清晰，回滚方便
- 真诚、友善、团结、专业2026-07-19
让ai写啊，不是有插件能获取git提交的文件分析一下就自动了，
- yuwk2026-07-19
- 722026-07-19
- 开远实验室🧪2026-07-19
现在用zed，全交给ai了```
"commit_message_instructions": "请深度分析以下代码变更，生成严格符合 Conventional Commits 规范的中文提交信息。格式为首行“<type>(<scope>): <核心概括>”，换行并空一行后，使用“-”无序列表详细列出具体的修改细节和技术实现，拒绝宽泛描述。" - wuang2026-07-19
