7.7 Git 工具 - Reset 詳解

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

實際上，要檢視這個快照的樣子非常容易。下面是一個示例，展示瞭如何獲取 HEAD 快照中每個檔案的實際目錄列表和 SHA-1 校驗和。

Git 的 cat-file 和 ls-tree 命令是“管道”命令，用於較低級別的操作，在日常工作中並不常用，但它們有助於我們理解這裡發生的事情。

索引是你**打算提交的下一個快照**。我們之前也把它稱為 Git 的“暫存區”，因為當你執行 git commit 時，Git 檢視的就是這裡的內容。

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

同樣，這裡我們使用了 git ls-files，這是一個更偏向幕後的命令，它展示了你當前索引的樣子。

技術上來說，索引並不是一個樹結構——它實際上被實現為一個扁平的清單（manifest）——但對我們目前的理解來說，已經足夠接近了。

最後，你擁有你的工作目錄（也常被稱為“工作樹”）。另外兩棵樹將它們的內容以一種高效但不方便的方式儲存在 .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 選項，允許你逐個 hunks 地選擇性地還原檔案內容。