前言
最近一直在研究 git 命令的操作效果，但總是感覺(jué)一知半解。自從看了知某平臺(tái)文章這才是真正的Git——Git內(nèi)部原理揭秘！，并結(jié)合git 圖解，才感覺(jué)了解了一些 git 背后的故事。
因?yàn)?git 的命令和參數(shù)眾多，初學(xué)者可以了解平常工作中經(jīng)常用到的命令，并了解這個(gè)命令干了什么事，比起強(qiáng)行記住而不知所以要好得多，而且印象也要深刻得多。
以下便是我看完后的一些總結(jié)，看之前可先將以上兩篇文章看完后再來(lái)閱讀，如有不對(duì)，還請(qǐng)指正。
Git 的三個(gè)分區(qū)以及本地文件的三個(gè)階段
1、三個(gè)分區(qū)
- 工作目錄 （ working directory ）：操作系統(tǒng)上的文件，所有代碼開(kāi)發(fā)編輯都在這上面完成。
- 索引（ index or staging area ）：可以理解為一個(gè)暫存區(qū)域，這里面的代碼會(huì)在下一次commit被提交到Git倉(cāng)庫(kù)。
- Git倉(cāng)庫(kù)（ git repository ）：由Git object記錄著每一次提交的快照，以及鏈?zhǔn)浇Y(jié)構(gòu)記錄的提交變更歷史。
2、三個(gè)階段
- git add 之前：工作區(qū)文件修改，不對(duì)索引和 git 倉(cāng)庫(kù)有任何影響
- git add 之后，git commit 之前：
在這個(gè)階段，我之前的理解就是把工作區(qū)修改的（跟暫存區(qū)之間比較差異的）文件快照放到暫存區(qū)，等著提交到 git 倉(cāng)庫(kù)?，F(xiàn)在的理解是基于 git 倉(cāng)庫(kù)里的實(shí)體來(lái)操作的。
實(shí)體對(duì)應(yīng)文章里的對(duì)象 object
根據(jù)這才是真正的Git——Git內(nèi)部原理揭秘！文章所說(shuō)，git add 操作分為兩步：
- 在 git 倉(cāng)庫(kù)產(chǎn)生類型為 blob 的實(shí)體
- 將暫存區(qū)對(duì)應(yīng)文件的索引更新為類型為 blob 的實(shí)體的索引
blob 實(shí)體：存儲(chǔ)文件內(nèi)容
- git commit 之后：同上分為三步
- Git 首先根據(jù)當(dāng)前的索引生產(chǎn)一個(gè)類型為 tree 的實(shí)體，充當(dāng)新提交的一個(gè)快照
tree 實(shí)體：存儲(chǔ)目錄結(jié)構(gòu)、文件名以及權(quán)限
- 創(chuàng)建一個(gè)新的 commit 實(shí)體，將這次 commit 的信息儲(chǔ)存起來(lái)，并且 parent 指向上一個(gè) commit，組成一條鏈記錄變更歷史。
commit 實(shí)體：存儲(chǔ)提交的作者、郵箱、日期、提交說(shuō)明等。
在查看 commit 實(shí)體的內(nèi)容 時(shí)除以上信息，還包含一個(gè) tree 實(shí)體，再次查看 ** tree 實(shí)體的內(nèi)容**，會(huì)發(fā)現(xiàn)包含一個(gè)或多個(gè) blob 實(shí)體， 繼續(xù)查看 blob 實(shí)體的內(nèi)容，會(huì)發(fā)現(xiàn)具體的文件內(nèi)容。
- 將當(dāng)前分支的指針移到新的 commit 結(jié)點(diǎn)。
PS：除了以上三個(gè)實(shí)體，還有一個(gè)實(shí)體為 tag
tag 實(shí)體：存儲(chǔ)指向特定提交對(duì)象（commit 實(shí)體）的引用
什么意思？
新建一個(gè)標(biāo)簽，取名 v1.0.0-release，它存儲(chǔ)著 commit 實(shí)體的引用，通過(guò)命令
> git cat-file -p ebb56c // ebb56c 為 v1.0.0-release 保存的 commit 實(shí)體的引用，即 sha1的前幾位字符
查看得到 commit 實(shí)體。
