7.7 Git 工具 - 重設機制解密

HEAD 是指向目前分支參考的指標，而分支參考又是指向該分支上最後一次提交的指標。這表示 HEAD 將會是下一次建立提交的父級。通常最簡單的方式是將 HEAD 視為您在該分支上最後一次提交的快照。

事實上，要查看該快照的樣子非常容易。以下是一個範例，說明如何取得 HEAD 快照中每個檔案的實際目錄列表和 SHA-1 總和檢查碼

Git 的 cat-file 和 ls-tree 指令是「底層」指令，用於較低階的事情，在日常工作中並非真正使用，但它們有助於我們了解這裡發生的事情。

索引 是您的建議下一次提交。我們也一直將這個概念稱為 Git 的「暫存區」，因為這是您執行 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 選項無法還原，因為它會強制覆寫工作目錄中的檔案。在這個特定的案例中，我們仍然在 Git DB 中的提交中擁有檔案的 v3 版本，我們可以透過查看我們的 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 選項，讓你能夠以逐塊的方式選擇性地還原檔案內容。