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

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

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

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

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

這個(gè)圖表現(xiàn)了多種場(chǎng)景，滿足了我們?cè)谑褂肎it時(shí)耳濡目染的操作情形。

場(chǎng)景1：暫存文件以及取消已暫存的文件

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

git add README.txt 

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

git commit -m "first commit" 

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

git rm --cached README.txt 

注意：此時(shí)取消暫存的文件從來(lái)就不曾提交過(guò)，也即是說(shuō)沒(méi)有在Git Repository留下過(guò)它的身影。這時(shí)的取消暫存實(shí)則是刪掉暫存的信息。與后面場(chǎng)景演示的取消暫存并不相同。

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

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

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

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

git reset HEAD README.txt 

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

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

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

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

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

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

git checkout -- hello.java 

在執(zhí)行checkout命令時(shí)要慎重。因?yàn)樗蜂N的內(nèi)容并沒(méi)有被放入到暫存區(qū)或Repository。一旦撤銷，就一去不復(fù)返了。

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

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

pull命令則除了會(huì)抓取數(shù)據(jù)，還能將遠(yuǎn)端分支自動(dòng)合并到本地倉(cāng)庫(kù)中當(dāng)前分支。

場(chǎng)景4：撤銷提交

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

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

git revert <commit> 

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

git revert HEAD~n 

如果是revert當(dāng)前提交，則不需要HEAD后的~n。

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

git reset <commit> 

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

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

git reset --hard <commit> 

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

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