有效率地使用 Git 仰賴一組精簡且可重複的十二個指令，並按照「先檢查再變更」的順序執行：初始化或複製（clone）儲存庫、讀取工作樹（working-tree）狀態、暫存（stage）刻意要做的修改、以帶有明確意圖的訊息提交（commit），再透過分支（branch）、擷取（fetch）與推送（push）的順序發布，以保留團隊共享的歷史紀錄。這件事之所以重要，是因為 Git 獎勵的是習慣，而非記憶：一位總是在暫存前先讀 status、在提交前先看 diff、在推送前先確認遠端狀態的開發者，極少會改寫歷史、遺失工作成果，或讓協作者感到意外。這些指令本身都很短，真正把工作副本轉化為乾淨、可復原歷史的，是它們的執行順序、它們的佔位符，以及包圍它們的檢查步驟。一份涵蓋設定、檢查、暫存、提交、分支、擷取與推送的精簡參考資料——並刻意省略破壞性的復原指令——比起一張把安全預設值與不可逆清理混為一談的龐大別名對照表，是更可靠的每日工作夥伴。
「有效率地使用 Git」真正的含義
Git 是一個內容定址（content-addressed）的檔案系統，頂層再加上一個傳輸層（transport layer），但多數日常工作其實歸結為四個問題：我在儲存庫的哪個位置、自上次查看以來變更了什麼、我想記錄什麼、以及它要如何離開我的機器。有效率的使用意味著用明確的指令來回答每個問題，而不是從終端機輸出、自動完成或記憶中的別名去猜測。區分一位有自信的 Git 使用者與一位謹慎使用者的，並不是指令的廣度——而是這種紀律：在 git add 之前執行 git status --short，在 git commit 之前執行 git diff，以及在 git push 之前執行 git fetch --prune。每一次檢查都只花不到一秒，卻能把假設轉化為證據。當省略了檢查步驟，那些平常能正常運作的同一批指令，就會偶爾覆蓋掉同事的分支，或把一份含有憑證的檔案意外地送進公開的提交（commit）裡。
有效率同時意味著選擇與現代 Git 官方文件一致的指令。switch 與 restore 已經取代 checkout 來處理分支與檔案移動；明確的 push 旗標（flag）取代了過去隱含的上游（upstream）行為；fetch 加上 prune 取代了手動清理遠端（remote）的舊做法。一份能跟上當前術語的參考資料，能讓你的肌肉記憶與隊友、程式碼審查者以及 CI 紀錄實際會印出的內容保持一致。
涵蓋日常工作的十二個指令
Git 速查表收錄十二個經來源核實的範本，每一項都已與官方 Git 參考手冊以及一份獨立的教學來源交叉比對。它們按工作流程階段而非字母排序，因此搜尋欄位能接受類別、動詞，或你心中所想的目的。
| 階段 | 指令範本 | 用途 |
|---|---|---|
| 設定（Setup） | git init | 在目前目錄下初始化一個新的儲存庫 |
| 設定（Setup） | git clone <url> | 下載既有的儲存庫及其歷史紀錄 |
| 檢查（Inspection） | git status --short | 摘要列出已追蹤、已暫存、已修改、已刪除以及未追蹤的路徑 |
| 檢查（Inspection） | git diff | 顯示尚未暫存的工作樹變更 |
| 檢查（Inspection） | git log --oneline --decorate -n 10 | 顯示 10 筆提交紀錄並標示分支與標籤 |
| 暫存（Staging） | git add <path> | 將特定路徑暫存到索引（index） |
| 提交（Commit） | git commit -m <message> | 以行內訊息記錄已暫存的快照 |
| 分支（Branch） | git branch --show-current | 印出目前分支的名稱 |
| 分支（Branch） | git switch <branch> | 切換到既有的本地分支 |
| 分支（Branch） | git switch -c <branch> | 建立新的本地分支並切換過去 |
| 遠端（Remote） | git fetch --prune | 下載遠端參考並移除過時的追蹤名稱 |
| 遠端（Remote） | git push -u origin <branch> | 發布目前的分支並記錄其上游（upstream） |
每一個項目都對應到上面提到的四個問題之一：clone 或 init 設定起點；三個檢查指令建立事實基礎；add 與 commit 記錄一份經過深思熟慮的快照；分支與遠端指令則在不重寫的情況下移動並發布該快照。這個組合刻意保持精簡。別名、底層（plumbing）指令與復原指令屬於篇幅更長的參考資料；每日的工作節奏則屬於簡短的版本。
如何從速查表取用一個指令
- 打開 Git 速查表，依指令名稱（例如 "fetch"）、類別（例如 "remote"），或目的（例如 "publish a branch"）來搜尋。
- 閱讀對應條目下的說明，並找出該指令所要求的所有尖括號佔位符——<url>、<path>、<message>、<branch>。
- 在複製之前，先在 shell 裡執行一次快速的前置檢查：使用 pwd 與 ls .git 確認工作目錄是儲存庫的根目錄，使用 git branch --show-current 讀取目前分支，並使用 git remote -v 確認已設定的遠端。
- 將每個佔位符（含括號本身）替換為實際的值，不要把尖括號逐字打進去。對於含有空格或對 shell 具有特殊意義字元的路徑或訊息，請加上引號。
- 複製解析後的指令，貼到 shell 裡，並擷取結束代碼（exit code）以及任何不敏感的輸出供日後檢視。
- 執行一次對應指令族系的後續檢查：暫存後跑 git status --short，提交後跑 git log --oneline --decorate -n 10，或是擷取遠端狀態後跑 git fetch --prune 緊接著 git branch -avv。
速查表是本機的、唯讀的，除非你主動選擇複製文字。它既不會開啟儲存庫，也不會執行任何指令，更不會上傳任何資料，因此關於 shell、工作目錄、hook 與團隊政策的責任，在每一步仍歸屬於操作者本人。
佔位符紀律與 Shell 引號用法
速查表中的每個範本都使用尖括號來標示讀者必須自行填入的值。請整段替換掉該佔位符，連同括號一起——git commit -m "Fix off-by-one in invoice total" 是正確的；git commit -m <Fix off-by-one in invoice total> 則不正確。若路徑或訊息中含有空格、撇號，或任何 shell 會解讀的特殊字元，請用一對對應的引號包起來，讓 shell 把單一參數完整傳給 Git，而不是將其切開。同樣的規則也適用於組件中含有冒號、`@` 符號或查詢字串的 URL。這一步的紀律，正是區分一段「靜悄悄就能成功」的複製貼上，與一段「靜悄悄就失敗」——甚至更糟，因為相對路徑解析到錯誤的檔案，而對錯誤的儲存庫成功執行——的複製貼上之間的分野。
當自動化程式呼叫 Git 時，請用絕對路徑鎖定工作目錄，明確處理非零的結束代碼，並擷取足夠的非敏感輸出以便診斷部分失敗，同時避免洩漏憑證。速查表本身不會儲存或傳送你代入的值，但你機器上的 shell 歷史紀錄會，因此絕對不要把祕密資訊貼進提交訊息或遠端 URL 中。
先檢查，再檢查一次
保護歷史紀錄的唯一習慣，就是在每一次變更（mutation）前後都執行檢查指令。git status --short 會給出每個路徑一行的摘要，短到每次都能完整讀完：兩欄分別代表索引與工作樹，再加上問號或驚嘆號標示未追蹤或被忽略的項目。git diff 顯示尚未暫存的工作樹變更；git diff --cached 顯示已暫存的變更，也就是提交實際會記錄的內容。在提交前讀過 diff，就能把「我好像只改了一行」轉化為一份逐行核對清單，逐一確認即將進入歷史的每一行。若需要更深入的檢查，並比對兩個分支以進行合併時，可以搭配分支差異比對指南使用。
精簡的帶裝飾（decorated）log 會顯示 10 筆提交紀錄與分支、標籤的指向，對於一般工作階段而言足以察覺錯誤的分支或漏掉的提交。更深入的診斷——bisect、路徑限制的 log、reflog——屬於更長篇的參考資料，但原則不變：閱讀儲存庫中實際的內容，而非你記憶中放進去的內容。在即將提交或推送前要再次檢查，因為在兩次檢查之間，另一個程序、編輯器、hook 或協作者都可能變更了檔案或參考。
速查表刻意省略的內容
一份精簡、供每日使用的參考資料，並不適合放 force push、git reset --hard、git clean、git rebase 或其他改寫歷史的指令。這些指令可能會丟失工作成果或改寫共享的歷史紀錄，且其安全性取決於儲存庫特有的情境：哪些分支受到保護、團隊是否對自家分支允許 force push、有哪些備份 ref 可用、哪些提交（commit）已經發布。把這些省略是有意為之的設計，而非缺漏。一個可複製的 git push --force 範本，無法提醒讀者同事一小時前剛推了兩個提交；而一個 git reset --hard 範本，也無法告訴讀者他即將遺失的工作其實從未被提交。涉及破壞性操作時，請同時參考Git 官方參考手冊以及專案的文件，並事先建立可復原的分支或備份。
速查表同樣不包含 rebase、cherry-pick、stash 或 submodule。這些指令在成熟的工作流程中都有一席之地，但單一開發者在單一儲存庫內的每日節奏，已被上面那十二個項目完整涵蓋。
A Repeatable Daily Routine With Git
Pull the twelve commands into a routine that mirrors the table. Start the day with git fetch --prune and a quick git status --short; switch or create the branch that matches the ticket with git switch or git switch -c; edit; read git diff to confirm what changed; stage with git add <path> rather than the entire tree; commit with git commit -m <message> that explains intent, not mechanics; and finish with git push -u origin <branch> on the first publish of a branch, or plain git push afterward. Each transition is gated by an inspection, so a wrong path or a missing file shows up before it enters history, not after a code review finds it.
The commands do not change because the project does — the same twelve entries work on a fresh git init, a freshly cloned open-source repository, or a long-lived monorepo. What changes is the discipline of running them in order, replacing placeholders honestly, and re-inspecting immediately before every commit and every push. That discipline is what "using Git effectively" really means, and it is what the Git Cheat Sheet is designed to reinforce. For background reading on the flags behind these templates, the Atlassian Git tutorials explain the same workflow with longer narrative context.