Git 命令速查表

速查表的真正用途

Git 的常用命令有一百多个，但大多数工程师每天真正使用的只有二三十个，其余的一年也用不了几次。速查表并不能替代对 Git 模型的理解，它的价值在于：把你本来就懂的命令放在一次按键的距离内，而不是一个浏览器标签页加三条搜索结果之外。

本页的参考表按真实工作顺序分组：初始化仓库、每天要跑几十遍的提交循环、分支操作、与远程仓库交互、查看历史，以及出问题后的补救。在筛选框中输入内容，命令文本和说明会同时被搜索，因此输入「stash」「force」或「撤销」都能立刻定位到相关条目。每一行都带有复制按钮——毕竟手敲一条含 --force-with-lease 的命令，正是打错字的高发场景。

命令背后的心智模型

只要记住三个位置，几乎所有 Git 命令都能讲通。工作区是你在编辑器里看到的磁盘文件；索引（也叫暂存区）是你正在为下一次提交组装的快照；仓库则是已经记录下来、不可变的提交链。git add 把内容从工作区送进索引，git commit 把索引变成一次新提交，而 git restore 则把内容往回推。

第二个概念是分支，它比看上去简单得多：分支只是一个指向某次提交的可移动指针，HEAD 则指向你当前所在的分支。创建分支几乎零成本，因为它只写入一个包含 40 位哈希的小文件。正因如此，git switch -c 便宜到可以为一个五分钟的小试验专门开一个分支。

合并与变基都是在整合两个分支的工作，差别在于记录方式。合并保留双方历史并新增一次连接提交，忠实但会形成交织的图。变基则重写你的提交，让它们看起来像是直接写在对方分支之上，历史变成一条直线，但提交哈希会改变——这也正是「绝不要对别人已经拉取过的提交做变基」这条规矩的由来。

出问题时如何补救

关于 Git 最值得记住的一点是：它极少真正弄丢已提交的内容。只要改动在某个时刻被提交过，git reflog 就能给出哈希，再用 git switch -c rescue <hash> 即可找回。这张安全网覆盖了变基失败、提交后误执行 reset --hard，以及删得过于果断的分支。

真正危险的操作是那些触碰未提交内容的命令：git reset --hard、对已修改文件执行 git checkout --，以及 git clean -fd。这些改动从未被记录，reflog 自然也无从指向。值得养成的习惯是：在临时分支上尽早、频繁地提交，或者在试验前先 git stash push。事后被压缩掉的提交毫无成本，而一下午未提交的工作是找不回来的。

在共享分支上，优先使用 git revert 而不是重写历史，它会新增一次抵消旧改动的提交，别人的克隆仍然有效。--force-with-lease 请只用于自己的特性分支；它明显比裸的 --force 安全：如果远程在你上次 fetch 之后发生了移动，它会直接拒绝执行，而这恰恰是裸强推会悄无声息毁掉同事提交的情形。