Git 的工作區、暫存區、版本庫

大家都知道，在 Git 系統中有 “三棵樹” 的概念。

注意：“樹” 在這裡的意思是 “檔案集合”，而不是指特定的資料結構。

基本概念

樹	用途
HEAD（版本庫）	上一次提交的快照，下一次提交的父結點
Index（暫存區）	預期的下一次提交的快照
Working Directory（工作區）	沙盒

HEAD

HEAD 是當前分支引用的指標，它總是指向該分支上的最後一次提交。 這表示 HEAD 將是下一次提交的父結點。 通常，可以把 HEAD 看做你的上一次提交的快照。可以簡單理解為： HEAD 指向分支（branch），分支指向提交。

Index

Index（索引，或暫存區）是你預期的下一次提交。這就是當你執行 git commit 時 Git 看起來的樣子。Git 將上一次檢出到工作目錄中的所有檔案填充到 Index，之後你會將其中一些檔案替換為新版本，接著通過 git commit 將它們轉換為樹來用作新提交。

工作目錄

另外兩棵樹以一種高效但並不直觀的方式，將它們的內容儲存在 .git 資料夾中。工作目錄會將它們解包為實際的檔案以便編輯。 你可以把工作目錄當做 “沙盒”，在你將修改提交到暫存區並記錄到歷史之前，可以隨意更改。

工作區、暫存區、版本庫原理圖

在這個圖中，可以看到部分 Git 命令是如何影響工作區和暫存區的。

圖中左側為工作區，右側為版本庫。在版本庫中標記為 index 的區域是暫存區。標記為master的是master分支所代表的目錄樹。

圖中可以看出此時HEAD實際是指向master分支的一個“遊標”。所以圖示的命令中出現HEAD的地方可以用master來替換。

圖中的 objects 標識的區域為 Git 的物件庫，實際位於 .git/objects目錄下。

1. 當對工作區修改（或新增）的檔案執行 git add命令時，暫存區的目錄樹被更新，同時工作區修改（或新增）的檔案內容被寫入到物件庫中的一個新的物件中，而該物件的 ID 被記錄在暫存區的檔案索引中。
2. 當執行提交操作 git commit 時，暫存區的目錄樹被寫到版本庫（物件庫）中，master 分支會做相應的更新。即 master 最新指向的目錄樹就是提交時原暫存區的目錄樹。
3. 當執行git reset HEAD命令時，暫存區的目錄樹會被重寫，被 master 分支指向的目錄樹所替換，但是工作區不受影響。
4. 當執行git rm --cached <file>命令時，會直接從暫存區刪除檔案（可以理解為取消跟蹤），工作區則不做出改變。
5. 當執行git checkout -- <file>命令時，會用暫存區指定的檔案替換工作區的檔案。這個操作很危險，會清除工作區中未新增到暫存區的改動。舉例來說：命令git checkout -- readme.txt意思就是把readme.txt檔案在工作區的修改全部撤銷，這裡有兩種情況：一是readme.txt自修改後還沒有被放到暫存區，現在，撤銷修改就回到和版本庫一模一樣的狀態；一種是readme.txt已經新增到暫存區，之後又作了修改，現在，撤銷修改就回到新增到暫存區時的狀態。
6. 當執行git checkout HEAD 或者 git checkout HEAD <file> 命令時，會用 HEAD 指向的 master 分支中的全部或者部分檔案替換暫存區和以及工作區中的檔案。注意，前者對工作目錄是安全的，Git 會通過檢查來確保不會將已更改的檔案弄丟；但是後者就危險了，也許會覆蓋工作目錄中對應的檔案！
7. 當執行 git reset HEAD <file> 命令時，它本質上只是將 file 從 HEAD 複製到索引中（可以理解為“取消暫存檔案” ）。
8. 當執行 git reset --hard HEAD 時，會用 HEAD 指向的 master 分支中的全部檔案替換暫存區以及工作區中的檔案。也就是說你撤銷了最後的提交（git commit ）、git add 和工作目錄中的所有工作，這樣做也是危險的，除非你真的想這麼做。
9. 也許你會問，git reset --hard HEAD 和 git checkout HEAD 這兩個命令有什麼區別呢？感覺它們乾的事情差不多啊。其實還有很大區別的，具體可以參考我的博文 git checkout 和 git reset 的區別

---

參考資料

【1】 廖雪峰：https://www.liaoxuefeng.com/wiki/

【2】《Git 權威指南》

【3】《Pro Git》（Scott Chacon, Ben Straub Version 2.1.14, 2018-05-19）