無論學習什么技術(shù)，都需要了解該技術(shù)的本質(zhì)。若是靠死記硬背該技術(shù)提供的方法或者語法，終歸是知其然而不知其所以然，當發(fā)現(xiàn)錯誤時，你根本不知道是什么原因?qū)е碌摹Ｎ以谑褂肎it時，就處于這種知其然而不知其所以然的狀態(tài)。現(xiàn)在，再來補補課。

Git有三個工作區(qū)域，分別為：工作目錄（Working Directory）、暫存區(qū)（Stage或Index）以及資源庫（Repository或Git Directory）。下圖是文件在這三個工作區(qū)域之間的關(guān)系：

參考Pro Git一書，它給出了Git的幾個要點： * 直接快照，而非比較差異：Git與其他版本管理系統(tǒng)的主要差別在于，Git只關(guān)心文件數(shù)據(jù)的整體是否發(fā)生了變化，而其他多數(shù)版本管理系統(tǒng)則只關(guān)心文件內(nèi)容的具體差異。Git并不保存文件前后變化的差異數(shù)據(jù)，更像是把變化的文件做一個快照，然后記錄在一個微型的文件系統(tǒng)中。每次提交更新時，會比較這個快照。若文件沒有變化，Git則只對上次保存的快照作一個鏈接。你可以理解Git就是一個小型的文件系統(tǒng)。 * 近乎所有操作都可本地執(zhí)行：無需多說，這本身就是分布式版本管理系統(tǒng)的特征。 * 時刻保持數(shù)據(jù)完整性：保存到Git前，所有數(shù)據(jù)都要進行內(nèi)容的校驗和（checksum），并將該結(jié)果作為數(shù)據(jù)的唯一標識。Git使用了SHA-1算法計算數(shù)據(jù)的校驗和，并將該結(jié)果作為索引，而非文件名。

* 多數(shù)操作僅添加數(shù)據(jù)

Pro Git一書認為任何一個文件在Git內(nèi)部可以被分為三種狀態(tài)：已提交（Committed）、已修改（Modified）和已暫存（Staged）。然而，這并不足以說明一個文件在不同的工作區(qū)域所展現(xiàn)的狀態(tài)。我認為兩種狀態(tài)足以表達Git中的文件，即：未跟蹤（Untracked）和已跟蹤（Tracked）。而對于已跟蹤狀態(tài)，我又將其分為：未修改的（Unmodified），Modified（已修改的），暫存的（Staged）和已提交的（committed）。下圖基本表達了我的思路：

這個圖表現(xiàn)了多種場景，滿足了我們在使用Git時耳濡目染的操作情形。

場景1：暫存文件以及取消已暫存的文件

可以參考上圖中上面部分黑色箭頭標示。當我們通過git init在本地初始化了Git工作目錄后，新增了一個README.txt文件時，此時該文件處于Untracked狀態(tài)。接下來執(zhí)行命令：

git add README.txt 

add命令可以暫存此文件，此時，狀態(tài)變更為Staged狀態(tài)，被放到了Git暫存區(qū)中。若我們要提交此文件到Git資源庫，就可以執(zhí)行g(shù)it commit命令，文件狀態(tài)變?yōu)閏ommitted。例如：

git commit -m "first commit" 

有時候，我們希望取消已暫存的文件。例如說，我在工作目錄中增加了兩個文件，然后暫存了它們。后來發(fā)現(xiàn)其中一個文件并不需要在Git中管理，希望能夠取消暫存。由于此時的文件處于Staged狀態(tài)，我們只需要刪掉Stage中對此文件的跟蹤即可。這時需要執(zhí)行的命令是：

git rm --cached README.txt 

注意：此時取消暫存的文件從來就不曾提交過，也即是說沒有在Git Repository留下過它的身影。這時的取消暫存實則是刪掉暫存的信息。與后面場景演示的取消暫存并不相同。

場景2：修改已提交文件以及取消已暫存的內(nèi)容

一旦文件被提交，就會在Git Repository形成提交記錄（以hash作為鍵）。倘若我們此時push提交到遠程Git服務(wù)器，Git服務(wù)器應(yīng)與本地庫保持一致。

現(xiàn)在，讓我們看看圖中紅色箭頭展現(xiàn)的流程。我們修改了已提交的README.txt文件，于是文件狀態(tài)就變更為Modified。這部分修改的內(nèi)容并沒有被放入暫存區(qū)，若要提交此次修改，就還需要再次執(zhí)行g(shù)it add命令，將這次新的修改放入到暫存區(qū)。這個流程包括后面的提交都與場景1相似。唯一不同的是“取消已暫存的內(nèi)容”。

雖然同樣是取消暫存，但它與場景1是完全不同的概念。場景1實則是要取消暫存區(qū)的文件，因此使用了git rm –cached，本質(zhì)上講其實是刪除。而這里的取消，其實是希望取消暫存區(qū)中已經(jīng)被添加的修改內(nèi)容，文件本身仍然保留在暫存區(qū)中。故而執(zhí)行的命令為：

git reset HEAD README.txt 

HEAD是何意呢？在Git中，HEAD是一個特別的指針，指向你正在工作的本地分支。當前分支就是master。如下圖所示：

而reset命令的意思是重新設(shè)置當前的HEAD指針到特定的狀態(tài)。由于當前的README.txt還沒有提交到master分支的Repository中。因此，這條命令實則就是將HEAD指向README.txt文件在當前master分支的Repository狀態(tài)，從而保證了對README.txt文件而言，暫存區(qū)與Repository的一致——取消了README.txt文件在暫存區(qū)的內(nèi)容。

場景3：修改文件以及撤銷修改內(nèi)容

再看圖中的綠色箭頭與藍色箭頭展現(xiàn)的流程。我們不是初始化git工作目錄，而是通過git clone從遠程Repository克隆了項目，此時會在當前目錄建立git工作目錄。此時的文件全部處于Unmodified狀態(tài)。

現(xiàn)在，我們修改文件，例如hello.java。一旦被修改，文件狀態(tài)就遷移到Modified狀態(tài)。倘若需要暫存此次修改，甚至提交到Git Repository，則執(zhí)行的流程與場景1相同（如藍色箭頭線所示）。

然而，我們可能希望放棄此次修改，即不將修改的內(nèi)容放入暫存區(qū)。這時，應(yīng)執(zhí)行checkout命令：

git checkout -- hello.java 

在執(zhí)行checkout命令時要慎重。因為它要撤銷的內(nèi)容并沒有被放入到暫存區(qū)或Repository。一旦撤銷，就一去不復(fù)返了。

概念區(qū)分：fetch vs. pull

fetch命令只是將遠端數(shù)據(jù)拉到本地倉庫，并不自動合并到當前工作分支。若要合并，還需手動合并。例如，執(zhí)行g(shù)it fetch origin，就會抓取自上次克隆以來別人上傳到此遠程倉庫中的所有更新。

pull命令則除了會抓取數(shù)據(jù)，還能將遠端分支自動合并到本地倉庫中當前分支。

場景4：撤銷提交

在Git中若要撤銷提交，可以使用reset或者revert命令。但二者有著顯著的區(qū)別：

revert命令可以撤銷已經(jīng)提交的快照，但它并不會將該提交從項目的提交歷史中移除，而是會判斷要撤銷的這次提交引入了哪些變化，然后將此變化撤銷（此次撤銷事實上還是一種變化），再將這次撤銷作為一個提交。因此，在執(zhí)行revert命令后，如果通過git log查看提交歷史，可以看到會新增一個revert提交。命令為：

git revert <commit> 

這個commit可以是指定提交對應(yīng)的hash code。我們也可以用HEAD指針：

git revert HEAD~n 

如果是revert當前提交，則不需要HEAD后的~n。

reset命令就字面意義已經(jīng)表達了該操作的含義為“重置”。由于Git的提交記錄是由HEAD指針指向當前分支。重置就是搬動這個指針到指定的snapshot。如果說revert是一種 安全的撤銷方式，則reset就是一種 危險的撤銷方式。默認情況下，如果使用reset命令，會將當前的分支回退到指定commit，然后自指定commit到***commit之間的內(nèi)容會放在工作目錄下，使得我們可以再提交。這個命令為：

git reset <commit> 

與前相同，這個commit就是提交對應(yīng)的hash code。同樣，也可以使用HEAD指針。不過如果是撤銷當前提交，與revert不同的是，需要指定為：HEAD~1。這是因為HEAD指針指向了當前提交。reset與revert的意義不一樣。revert對應(yīng)的commit為目標提交，意思為：“撤銷目標提交”，因而git revert HEAD，代表的就是“將當前提交撤銷”。而reset對應(yīng)的commit表示將指針移向給定的Commit。如果執(zhí)行g(shù)it reset HEAD，代表的就是“將當前指針指向當前提交”，相當于沒做任何操作。所以應(yīng)該執(zhí)行g(shù)it reset HEAD~1。

如果確實要撤銷操作，而前面的內(nèi)容并不需要，在使用reset命令時，可以添加–hard參數(shù)：

git reset --hard <commit> 

**注意：針對遠程的提交記錄，應(yīng)盡量避免使用git reset命令。倘若在本地進行了reset之后，又進行了另外的修改并提交。此時，本地的提交記錄與遠程的提交記錄在reset的那個點產(chǎn)生了分叉。如下圖所示： 

此時，如果執(zhí)行g(shù)it push，會在本地合并后提交，并同步遠程提交記錄。則團隊其他成員會因為這個變化的提交記錄而困惑。由于一部分變更消失，甚至可能導(dǎo)致一些數(shù)據(jù)被破壞。因此，使用reset命令要格外當心，通常情況，應(yīng)盡量針對本地提交（未push到遠程）進行reset。優(yōu)先考慮使用revert命令。