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 之後發生了移動，它會直接拒絕執行，而這恰恰是裸強推會悄無聲息毀掉同事提交的情形。