Git 版本控制的正确打开方式

Git 大概是程序员世界里使用频率最高的工具之一，但很多人对它的理解只停留在 add、commit、push 三步，把它当成一个”云端备份”来用。这其实远远没有发挥出 Git 真正的价值——管理变化的完整历史。

这篇不打算罗列命令手册，而是聊聊一些更重要的观念和习惯。

Git 到底在管什么#

理解 Git，先要理解它记录的是”快照”和”差异”：每一次提交都是当时整个项目状态的一次定格，而分支则是在这串历史之上分叉出的平行时间线。

这意味着你可以：

把它当成备份，是暴殄天物；把它当成历史记录和协作工具，才算是用对了。

想清楚这一点特别重要，因为它决定了你后面所有的使用习惯。一旦你意识到每一次提交都在为未来的自己留下一份”可回放的档案”，你就不会再随手写一句”改了一下”了。反过来，如果只把它当网盘，那么提交信息、分支策略这些就都变成了多余的负担。

提交是最小的记录单元，它的质量直接决定了历史的可读性。

好的提交信息应该能回答两个问题：做了什么、为什么做。我习惯遵循约定式提交的格式：

1
feat: 添加文章搜索功能
2
fix: 修复移动端侧边栏错位的问题
3
docs: 更新使用文档

类型标签放在最前面，一眼就能看出这条提交的性质。尽量避免 update、改了一下 这种说了等于没说的描述。

好的提交信息是写给自己和同事的”未来说明”。三个月后你回看历史，靠的正是这一行行描述去理解当时的思路。如果每条都是”改了一下”，那份历史就成了一团看不清的浆糊。多花十秒钟写好描述，回报的是日后数不清的省心。

一次提交最好只做一件事。不要”改 bug 顺便又重构了整个文件”混在一条提交里，否则日后想单独回滚某一部分会非常麻烦。

保持提交细碎还有一个实际好处：当你发现自己改错了方向，可以精准地退回某一个小步骤，而不是把一整天的成果一起丢掉。小步前进，等于给自己多留了几条后路。

频繁地在 main 上直接提交，很快就会把主干搞得一团糟。一个简单实用的做法是：

即使是我一个人的个人项目，我也会习惯开分支。它让”尝试一个想法、不行就放弃”的成本变得几乎为零。

分支听起来是多人协作才需要的东西，其实一个人同样受益。开一个分支做实验，做好了合并，做砸了删掉分支，主干纹丝不动。这种”零风险的尝试”能鼓励你大胆动手，而不是每次改代码都提心吊胆。

这里我想重点强调”提交前看一眼差异”。很多事故都源于粗心：把密钥、临时调试代码、不该改的文件一起提交了进去。养成 git diff 再 commit 的习惯，就像出门前检查一下口袋，能避免无数尴尬和麻烦。

这是个经典话题，我的简单原则是：

一句话总结：不要对已经推到远程、可能有别人使用的分支随意 rebase，会改写给别人的历史。

对新手来说，最稳妥的做法是先把 merge 用熟。rebase 带来的线性历史确实好看，但它改写了提交历史，一旦用在公开分支上就可能给协作者带来麻烦。等你对提交历史有了足够的理解，再在自己的本地分支上尝试 rebase 也不迟。

工具终究是为人服务的。Git 的种种概念初看复杂，但一旦理解了”它是在记录变化历史”这个核心，很多命令就不再是死记硬背。慢慢来，先养成小步提交和好好写提交信息的习惯，其余的自然会水到渠成。

如果你现在还用得磕磕绊绊，别灰心。每个人都是从”什么时候该 add、什么时候该 commit 都分不清”的阶段走过来的。把每一次提交都当成一次对历史的认真书写，你的 Git 水平会随着这个习惯一起成长。