Git：我什么时候开始怕「改不回去」的

速读#

这篇不是 Git 命令大全，而是记录我什么时候开始把“能回去”当成写代码的安全感来源。最重要的习惯是改之前先有可回退点，.gitignore 和第一条 commit 同时出现，密钥和环境文件别进库。

开始写代码之后，最先撞上的往往不是语法报错，而是：改了半天想回滚，文件已经被覆盖了。

最痛的一次：改了一晚上，中途几次「顺手优化了一下别的地方」，最后想退回能跑的版本——那个版本从来没存过。

那次之后多了一条判断：改代码之前，先确认能回去。 提交不是负担，是安全绳。版本控制的核心价值不在「管理」，在可回退：每一次提交是一个可命名的存档点。没有这层，改代码就是单向的——文件一覆盖，过去就没了。

git add main.py
git commit -m "feat: 初始化项目"
git push -u origin main

这条肌肉记忆是后面所有东西的前提：写 Python 用它管代码，学 Docker 从仓库拉配置，CI/CD 直接建立在 Git 工作流上。

提交信息也别糊弄。「动词 + 干了什么」就够，但要写实——存档点的名字是给未来翻 git log --oneline 的自己看的，一排「update」等于没写。

提交的粒度同理：一次提交尽量只做一件事。回退是以提交为单位的，一个存档点里混着三个不相干的改动，想退其中一个就只能三个全退——存档点切得细，退路才是精确的。 那晚白干还有另一半教训也在这：几处「顺手优化」和主线改动搅在同一摊里，就算当时想抢救，也分不出哪些该留哪些该扔。

虚拟环境、编译产物、密钥文件不该进库。我后来几次「密钥差点提交」，都是靠 gitignore 兜的。

.gitignore 和第一条 commit 同一时间点写。 配置密钥这一面，从第一天就该和变更面一起想——临时的就是永久的。

还有一条规矩提前想好：密钥真提交了、也推出去了，就直接按泄露处理，立刻作废换新。从历史里抹掉那次提交技术上做得到，但「删掉了」和「没存在过」是两回事——别赌没人拉取过。

分支是「平行宇宙」——试新东西不影响主线，试废了删掉。但 rebase 和 merge 的区别，我直到国庆帮人合代码时都还没真正分清。

诚实写当时的判断：

该不该上某套分支策略：这个规模下它是在帮我，还是在制造没必要的复杂度？规模到了，复杂度会来找你；没到之前，简单就是对的。

Git 教会我的不是命令表，是把「怕改错」变成「敢改」。能回到任何一步之后，写代码的心理成本会明显下降。