Git 救火指南：那些年我踩过的坑

如果 Git 是一个游戏，那 git reset --hard 绝对是那个让你“删号重练”的按钮。

昨天有个刚入行的朋友问我：“Git 到底要学多少命令才够用？”他看着那本几百页的权威指南，眼神里充满了绝望。

我说，说实话，我用了这么多年 Git，真正救命的也就那几个。

很多时候，我们并不需要一本百科全书，我们需要的是一个急救包——当你搞砸了，手心冒汗，老板就在你身后盯着的时候，能一眼看到的救命稻草。

这篇文章不讲原理（DAG、Merkle Tree 留给面试），只讲生存。

1. 想要“打包带走”的时候

我是真的遇到过这种情况：老板不懂 Git，非要我把源码“发个包给他”。

以前我会傻傻地手动复制文件，还要一个个删掉 node_modules 和 .git 目录，搞得狼狈不堪。一边删一边担心：万一漏删了私钥文件怎么办？

后来我发现，Git 原来自带了“打包”功能。

这一行命令，能救命：

git archive --format=zip --output source-code.zip master

它会自动忽略 .gitignore 里的文件，生成的压缩包极其纯净。那一刻我才觉得，Git 是真的懂程序员的。它就像一个贴心的管家，帮你把房间打扫得干干净净再交给客人。

2. 只有上帝知道我刚才写了什么

有时候写嗨了，把还没写完的脏话或者 Token 提交了上去。这时候如果不处理，这些“黑历史”就会永远留在 Commit Log 里，成为同事们茶余饭后的谈资。

如果你还没 Push，还有救：

# 方案 A：软着陆（推荐）
# 撤销提交，但保留你写的代码。就像时间倒流，但记忆保留。
git reset --soft HEAD~1

# 方案 B：硬着陆（慎用！！！）
# 彻底抹除最后一次提交，就像它从未发生过。
# 我只在深夜头脑发热写了一堆垃圾代码时才用它。
git reset --hard HEAD~1

把 reset --soft 想象成游戏里的“读档”，你可以重新来过，装备还在。

3. 捉鬼游戏：这行代码到底是谁写的？

线上出了 Bug，代码逻辑看起来极其愚蠢。你怒气冲冲地想找出是哪个“天才”写的，准备去 Battle 一番。

git blame filename.ts

这个命令会把每一行代码的作者和修改时间列出来。

温馨提示：在按下回车之前，请做好心理准备。因为很多时候，你会发现那个“天才”竟然是三个月前的你自己。

这时候，原本准备好的怒火只能默默咽回去，还得假装若无其事地修好它。这可能就是成长的代价吧。

4. 正在修 Bug，老板突然让我切分支

这绝对是开发者最讨厌的场景：你的工作区一团糟，代码写了一半，逻辑还没跑通。这时候老板冲过来说：“线上有个紧急 Bug，马上修一下！”

你不想 Commit（因为代码是坏的），也不想丢掉进度。

这时候，你需要一个“时间胶囊”：

# 1. 把案发现场封存起来
git stash

# 2. 现在工作区干净了，切分支去救火吧
git checkout hotfix-branch
# ... 修 Bug，提交，上线 ...

# 3. 救火结束，切回来
git checkout my-feature

# 4. 打开时间胶囊，恢复现场
git stash pop

每次用 git stash pop 看着代码重新出现的时候，我都有一种“这就是魔法”的错觉。它就像是你在这个平行宇宙按下了暂停键，去另一个宇宙拯救完世界回来，一切如初。

5. 记忆碎片：我记得我写过这行代码...

你是不是也有这种时候？明明记得写过一个很巧妙的 TODO 或者一个特殊的函数名，但死活找不到在哪个文件里了。翻遍了十几个文件，眼睛都花了。

别用编辑器的搜索了，用 Git 的搜索：

# 在所有文件中搜索 "TODO"，速度快到飞起
git grep "TODO"

# 甚至可以在历史版本里搜（比如 5 次提交前）
git grep "function_name" HEAD~5

---

Git 很强大，也很可怕。

我现在的原则是：在该 Commit 的时候 Commit，在该 Push 之前三思。

希望这份手册能帮你少掉几根头发。

END