🔗 项目地址:https://github.com/alekschen/ai-commit
作为开发者,我们都经历过这样的时刻:辛辛苦苦写完了一天的代码,到了提交的时候,大脑却一片空白。最后只能草草写下 fix bug、update 或者 temp 这种毫无意义的提交信息。
过段时间回看 git log,完全想不起来当时改了什么。
今天向大家推荐一款开源神器 —— AI Commit (@alekschen/ai-commit)。它能根据你的 git diff 自动生成符合 Conventional Commits 标准的提交信息,而且最重要的是:它绝对安全,隐私优先。
running.gif
在引入 AI 工具辅助编程时,代码安全是所有开发者最关心的问题。AI Commit 在设计之初就将隐私放在了第一位:
不仅是写出“人话”,更是写出“标准话”。生成的提交信息自动遵循行业标准格式:
feat: 新功能fix: 修补 Bugdocs: 文档改变refactor: 代码重构
...以及更多。AI Commit 的工作流程简洁而高效。它充当了你的 Git 环境与大语言模型之间的本地安全桥梁。
以下是其核心处理流程图:
zh_uml.png
从图中可以看到,代码数据的流动是点对点的(从你的电脑 -> API 提供商),ai-commit 仅仅是一个运行在本地的“搬运工”和“翻译官”,确保了数据链路的最短和最安全。
确保你的 Node.js 版本 >= 18.0.0:
npm install -g @alekschen/ai-commit
设置你的 API Key (支持 OpenAI 或兼容服务商):
ai-commit config
在交互式菜单中,你可以设置 API 地址、Key 、模型偏好以及输出语言(记得选中文!)。
当你修改完代码并 git add 后,只需输入:
ai-commit
工具会立即分析你的变更,并给出几个生成的提交建议。你可以:
担心 Token 用超了? AI Commit 内置了统计功能。
运行 ai-commit cost,你可以清晰地看到:
写代码是创造性的工作,写 Commit Message 则是重复性的劳动。把重复的工作交给 AI ,把精力留给核心逻辑。
AI Commit 不仅是一个工具,更是你代码仓库的“管家”,帮你维护一份清晰、规范、可追溯的历史记录。
🔗 项目地址:https://github.com/alekschen/ai-commit
🌟 如果你觉得好用,欢迎给项目点个 Star !
1
xjiang1982154112 PRO 程序员最怕的两件事
1 、取变量名 2 、写 commit message |
2
Aleks OP @xjiang1982154112 打磨工具,我自己用了很久,现在提交代码不苦恼了。以前最烦这个了
![]() |
3
iyeatse 23 小时 53 分钟前 via iPhone 一直都用 claude code ,直接说 commit and push 就行;
Fork app 好像也有这个功能 |
4
SilencerL 23 小时 4 分钟前 使用 VS Code 的可以尝试这里
![]() 配置 prompt: 添加/编辑 .github/copilot-commit-message-instructions.md 参考: https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions |
5
idealx 9 小时 38 分钟前
这个功能是现代的 AI IDE 的标配了
|
6
94 6 小时 46 分钟前
> 辛辛苦苦写完了一天的代码,到了提交的时候,大脑却一片空白。
所以才要小步提交,干完一件事就提交一次,而不是把一天所有输出的内容在一个 Commit 中一下子全提交上去…… 如果嫌提交的 commit 太多了,最后在 MR/PR 之前用 squah 把相关的 commsit 合并起来。 |
8
Aleks OP @idealx 是的,Github Copilot 、Cursor 、Antigravity 和 CC 都有自动生成 message 的功能,实现原理都是一样。
|
9
94 4 小时 59 分钟前
@Aleks #7 ,还好吧,就说一下这个是什么功能,或者修了什么 bug 就行了。简短明了,也不用说的很清楚。
按照格式第一行是 title ,第三行开始才是 details 。 毕竟在写代码的时候其实就是知道自己现在在干什么的。很多时候我可能都会先写好 Commit Message 再开始写代码。因为叉出来的分支就已经是 `fix/dashboard-charts-style-issue` 的形式了 大部分情况都是简单的 `fix(dashboard): 修复 XX 图表的显示问题`。 如果没有特别需要备注的就是直接提交了,如果有一些特殊备注才会另起一行单独写内容。 ``` fix(dasboard): 修复 XX 图表的显示问题 - 修复遇到页面缩放时图表文字过大; - 修复多图表标题未联动; ``` 但其实这些 details 应该在提交的时候拆开来提交,最后在 squash 的时候,再把一些小步提交的信息放到 details 中,然后标题就是简单的概括成是 “fix(dasboard): 修复 XX 图表的显示问题”。 |
10
Aleks OP @94 #9 先写好 Commit Message 再开始写代码。这种范式蛮牛的,我还是头一次听说。改动问题边界清晰可预判的情况,这样没问题的。
但对于一些改动量大,没有及时拆分成小步提交的情况下,用 AI 省事一些。人写 message 其实和 AI 写是一样的,AI 只是把流程自动化了。二者本质上一样的,只是行为主体不一样。 |
11
94 4 小时 26 分钟前
@Aleks #10 ,习惯一个好的工作流很重要。某一个调整的改动量大没关系,但没有小步提交/限制影响范围的话,可能会在发布环节造成困扰。
以前经常会遇到一些同事在开发的时候用一个提交混合了几个调整,或者用一个分支去开发多个功能或者调整。 如果有一些因为测试没通过,或者临时决定暂停开发。就会拖累其他的功能的正常发布。 虽然可以通过 rebase 调整或者拆分单一开发分支来解决。但是如果遇到一个提交中包含了多个调整的情况,那么就很麻烦了。特别是遇到两个功能还改到同一个文件,真的会麻烦。很多人不知道要怎么去操作。 所以在前期稍微麻烦一下,后面就算遇到问题也会容易解决起来。 ----- 用简短的话去描述,大部分开发同事都是可以的,但遇到总结汇报真的是大部分开发同事的噩梦,很多还有数字要求。所以我一般在这个阶段用 AI 读 Git Commit 去写工作总结 😂 |