7.7 Git 工具 - 揭秘 Reset

HEAD 指向當前分支的引用，而該引用又指向該分支上最後一次提交。這意味著 HEAD 將是下一次建立的提交的父提交。通常，最簡單的理解方式是把 HEAD 看作是你在該分支上最後一次提交的快照。

事實上，檢視該快照的內容非常容易。下面是一個獲取 HEAD 快照中每個檔案的實際目錄列表和 SHA-1 校驗和的示例：

Git 的 cat-file 和 ls-tree 命令是用於底層操作的“管道（plumbing）”命令，在日常工作中並不常用，但它們能幫助我們理解這裡發生了什麼。

索引 是你建議的下一次提交。我們也將這個概念稱為 Git 的“暫存區”（Staging Area），因為當你執行 git commit 時，Git 就是檢視這裡的內容。

Git 會用上次檢出到工作目錄中的所有檔案內容及其原始狀態來填充此索引。然後，你可以用檔案的新版本替換其中一些檔案，git commit 會將這些更改轉換為新提交的樹。

同樣，這裡我們使用了 git ls-files，它更像是一個幕後命令，能顯示你的索引當前的狀態。

從技術上講，索引並非樹形結構——它實際上被實現為一個扁平化的清單——但就我們的目的而言，這樣理解就足夠了。

最後，你擁有你的 工作目錄（也常被稱為“工作樹”）。其他兩棵樹將內容以高效但不方便的方式儲存在 .git 資料夾內。工作目錄將它們解包成實際的檔案，這使得你可以更輕鬆地編輯它們。將工作目錄視為一個沙盒，你可以在將更改提交到暫存區（索引）並最終提交到歷史記錄之前，在這裡嘗試修改。

reset 要做的第一件事就是移動 HEAD 指向的位置。這與更改 HEAD 本身（checkout 的作用）不同；reset 移動的是 HEAD 所指向的分支。這意味著如果 HEAD 設定為 master 分支（即你當前在 master 分支上），執行 git reset 9e5e6a4 將首先使 master 指向 9e5e6a4。

無論你呼叫帶有提交的何種形式的 reset，這都是它總是會嘗試做的第一件事。使用 reset --soft 時，它將僅僅停在這裡。

現在花點時間看看那張圖，並理解發生了什麼：它實質上撤銷了上次的 git commit 命令。當你執行 git commit 時，Git 會建立一個新的提交，並將 HEAD 指向的分支向上移動到該提交。當你 reset 回到 HEAD~（HEAD 的父提交）時，你是將分支移回到它原來的位置，而不改變索引或工作目錄。你現在可以更新索引並再次執行 git commit 來完成 git commit --amend 所能做的事情（參見修改最後一次提交）。

請注意，如果你現在執行 git status，你將看到索引與新的 HEAD 之間的差異以綠色顯示。

reset 接下來會做的是用 HEAD 當前指向的快照內容來更新索引。

如果你指定 --mixed 選項，reset 將會停在此處。這也是預設行為，因此如果你根本不指定任何選項（在此例中僅使用 git reset HEAD~），命令也會停在這裡。

現在再花一秒鐘看看那張圖，並理解發生了什麼：它仍然撤銷了你的上次 commit，但也取消暫存了所有內容。你回滾到了執行所有 git add 和 git commit 命令之前。

reset 將要做的第三件事是使工作目錄看起來與索引一致。如果你使用 --hard 選項，它將繼續執行到此階段。

那麼，讓我們想想剛才發生了什麼。你撤銷了最後一次提交，撤銷了 git add 和 git commit 命令，以及你在工作目錄中完成的所有工作。

重要的是要注意，這個標誌（--hard）是使 reset 命令變得危險的唯一方式，也是 Git 實際會銷燬資料的極少數情況之一。reset 的任何其他呼叫都可以很容易地撤銷，但 --hard 選項不能，因為它會強制覆蓋工作目錄中的檔案。在這個特定情況下，我們的檔案 v3 版本仍然存在於 Git 資料庫的一個提交中，我們可以透過檢視 reflog 來找回它，但如果我們沒有提交它，Git 仍然會覆蓋檔案，而且將無法恢復。

reset 命令以特定順序覆蓋這三棵樹，並在你告知時停止

執行 git checkout [branch] 與執行 git reset --hard [branch] 非常相似，因為它都會更新所有三棵樹使其看起來像 [branch]，但有兩點重要的區別。

首先，與 reset --hard 不同，checkout 是工作目錄安全的；它會檢查以確保不會清除已更改的檔案。實際上，它比這更智慧一些——它會在工作目錄中嘗試進行一次簡單的合併，因此你未更改的所有檔案都將被更新。而 reset --hard 則會不經檢查地直接替換所有內容。

第二個重要區別是 checkout 更新 HEAD 的方式。reset 會移動 HEAD 所指向的分支，而 checkout 會移動 HEAD 本身去指向另一個分支。

例如，假設我們有 master 和 develop 分支，它們指向不同的提交，並且我們當前在 develop 分支上（因此 HEAD 指向它）。如果執行 git reset master，develop 本身現在將指向與 master 相同的提交。如果我們改為執行 git checkout master，develop 不會移動，而是 HEAD 本身移動。HEAD 現在將指向 master。

因此，在這兩種情況下，我們都將 HEAD 移動到指向提交 A，但如何移動卻大相徑庭。reset 會移動 HEAD 所指向的分支，checkout 會移動 HEAD 本身。

執行 checkout 的另一種方式是帶檔案路徑，這和 reset 一樣，不會移動 HEAD。它就像 git reset [branch] file 一樣，用該提交中的檔案更新索引，但它也會覆蓋工作目錄中的檔案。它會完全等同於 git reset --hard [branch] file（如果 reset 允許你那樣執行的話）——它不是工作目錄安全的，並且不會移動 HEAD。

此外，與 git reset 和 git add 類似，checkout 也接受 --patch 選項，允許你逐個塊地選擇性地恢復檔案內容。