从GitHub入门讲起
如果你看过本站的文章 #16 从零开始注册GitHub并克隆仓库，那你的Git之旅应该已经上路了——你学会了git clone把项目拉下来，学会了git add .把改动的文件扔进去，学会了git commit -m "信息"，然后git push推上去。
一切顺利。直到某个时刻，你发现每次都要写"信息"太麻烦了。于是你开始写"1"。
$ git push
代码能提交，能推送，GitHub上也能看到。看起来一切正常。而且确实——在某个特定的时间窗口内，它就是正常的。
但这篇文章不是来跟你说"1"有多好用的。这篇文章是来告诉你，它为什么从根上就是烂的。
首先把话说清楚：短期写"1"没什么大不了的
很多Git教程一上来就摆架子说"commit message必须用规范格式"、"不符合Conventional Commits的都是垃圾"——没必要，真的。如果满足以下全部条件：
- 你一个人写，没有协作者
- 项目还不稳定，一天改很多次
- 你记得每个改动，脑子比git log好用
那你写"1"完全OK。这时候项目还在原型阶段，最核心的任务是让东西跑起来。没人会在原型期去翻commit log找历史。
这就是所谓的"短期容忍区"。在这个区间内，commit message的质地根本不重要，因为唯一的读者就是你自己，而你当时全记得。
答案很简单——当你开始需要回头看的那一刻，"短期"就结束了。这个时刻可能是你第一次
git log想找一个旧功能，也可能是你第一次把代码发给别人看。
但当你开始认真做项目，"1"就是灾难
长期项目的本质是：你一定会忘记自己写过什么。人脑不是数据库，三个月后的你回头看自己写的代码，和看一个陌生人写的东西基本没区别。而commit log就是你留给未来的自己的唯一指引。
现在来看一下，用"1"写commit log会发生什么：
1. git log 变成了天书
a1b2c3d 1
d4e5f6g 1
g7h8i9j 1
j0k1l2m 1
m3n4o5p 1
p6q7r8s 1
全是"1"。你能分出哪个加了新功能，哪个修了bug，哪个只是改了README里的一个标点？不能。你只能一个一个commit去翻diff。
如果有12个commit全是"1"——恭喜你，你得看12次diff才能找到你想要的那次改动。而如果项目有100个commit……我建议你直接重写。
2. git bisect 直接报废
git bisect是Git里最漂亮的调试工具之一：通过二分查找，帮你精准定位哪个commit引入了某个bug。但它的前提是——每一个commit都有一个清晰的标签，让你知道它在bisect的二分过程中该不该标记为good。
如果每个commit都是"1"，bisect工具本身还能用，但你的体验会变成：
# 这是好的吗？这个"1"改了啥来着……
$ git show --stat
# 哦，改了登录页面……等下，bug是不是登录相关来着？
你每次都要手动git show来看这个"1"到底改了什么东西。本来几秒钟的bisect过程，被硬生生拖成几分钟的"猜谜游戏"。
3. 三个月后的你，是最熟悉的陌生人
这是最致命的问题。你现在觉得"反正我都记得"——但三个月后你绝对不记得。你甚至连"1"这个commit是在哪一天写的都记不清。
你的项目在成长。从10个文件到50个文件，从500行到5000行。到了某个节点，你突然需要一个两周前写的函数，但你不确定它在哪个文件里——你翻开git log：
a1b2c3d 1 # 是这个吗？
d4e5f6g 1 # 还是这个？
g7h8i9j 1 # 或者这个？？
每一个"1"都是一扇上锁的门。你要一把一把钥匙去试。运气好试到第三把，运气不好——十把钥匙全试完也没找到，最后还是用grep -r全文搜索找代码。
那Git的版本控制意义在哪里？你明明有一个完整的历史记录，却因为每个commit都叫同一个名字，让这个记录变成了废物。
好，那什么样的commit才是好的？
其实根本不用背什么Conventional Commits规范。在你学会那些花里胡哨的格式之前，先做到一条最基本的：
让你的commit message有意义。
就这么简单。"有意义"的意思是：别人（包括三个月后的你）看到这条信息，不用点开diff就知道这次commit干了什么。
❌ 反面教材
1
2
a
x
fix
update
asdf
111
.✅ 合格标准
修复登录按钮在移动端不可点击
添加用户头像上传功能
删除过时的API路由
重构数据库查询为异步
更新README安装说明看到区别了吗？右侧每一条你都知道它在做什么，左侧你完全不知道。这就是"有意义"和"没意义"的差距。
再进一步，如果你想让log更好用，可以加一点简单的约定：
$ git commit -m "fix: 修复登录按钮不可点击" # 修bug
$ git commit -m "refactor: 提取validateEmail" # 重构
$ git commit -m "docs: 更新README" # 文档
这种做法叫"Conventional Commits"，但它不是强制规范——它只是把你已经在做的事情加上一个分类前缀，让log立刻变得可筛选、可搜索、一目了然。
合作场景："1"等于在谋杀团队效率
如果上面的内容还只是"个人开发者不痛不痒"的问题，那么多人协作时写"1"就是在犯罪了。
想象一下：你的队友A刚刚提交了一个commit，message写的是"1"。你想知道他改了什么地方——你只能去看diff。如果他也忘了，你们俩还得打开PR页面从头看到尾。
再来想象：你在review队友B的PR，里面5个commit分别是"1"、"2"、"3"、"fix"、"a"。你需要搞清楚每个commit改了什么，逐一对比。一个本来10分钟能搞定的review，硬生生拖了半小时。
在团队里，commit message就是你和队友之间的快照。你省掉的那几个字，乘以团队人数，就是浪费的总时间。
总结：一条线
总结一下，这条线其实很清楚：
- 个人原型开发：写"1"可以。项目不稳定、改动频繁、根本没人看历史——这个阶段commit message的优先级是0。
- 认真开发 / 团队协作：必须写有意义的信息。这个"信息"不需要是长篇大论，一句话说清楚"干了什么"就够了。
commit message不是写给Git看的。是写给未来的自己（和你的队友）看的。
Git 本身不关心你写了什么
你可以写"1"，可以写"a"，可以写"111"，甚至可以写空字符串。
Git照常工作——它只负责记录快照。
但你不一样。你需要理解历史。
三个月后的你翻开 log，看到的是一片"1"——
那不是Git的错。
是你自己选择毁掉了自己的项目历史。
# git commit -m "一个有意义的描述"
# 这不是规范，这是尊重——尊重未来的自己
「我现在懂了——不是Git在惩罚我写'1'，是三个月后的我在诅咒现在的我。」
