簡(jiǎn)單地說(shuō)，Git 究竟是怎樣的一個(gè)系統(tǒng)呢？請(qǐng)注意接下來(lái)的內(nèi)容非常重要，若你理解了 Git 的思想和基本工作原理，用起來(lái)就會(huì)知其所以然，游刃有余。在學(xué)習(xí) Git 時(shí)，請(qǐng)盡量理清你對(duì)其它版本管理系統(tǒng)已有的認(rèn)識(shí)，如 CVS、Subversion 或 Perforce， 這樣能幫助你使用工具時(shí)避免發(fā)生混淆。盡管 Git 用起來(lái)與其它的版本控制系統(tǒng)非常相似， 但它在對(duì)信息的存儲(chǔ)和認(rèn)知方式上卻有很大差異，理解這些差異將有助于避免使用中的困惑。

Git 初始化代碼倉(cāng)庫(kù)

執(zhí)行完成了 git init 命令，究竟做了什么呢？ 執(zhí)行完成如下命令之后，我們可以得到下圖所示的內(nèi)容，右側(cè)的就是 Git 為我們創(chuàng)建的代碼倉(cāng)庫(kù)，其中包含了用于版本管理所需要的內(nèi)容。

#左邊執(zhí)行 $mkdirgit-demo $cdgit-demo&&gitinit $rm-rf.git/hooks/*.sample #右邊執(zhí)行 $watch-n1-dfind.

我們這里可以一起看下生成的 .git 目錄的結(jié)構(gòu)如何：

?tree.git .git ├──HEAD ├──config ├──description ├──hooks ├──info │└──exclude ├──objects │├──info │└──pack └──refs ├──heads └──tags

.git/config- 當(dāng)前代碼倉(cāng)庫(kù)本地的配置文件

• 本地配置文件（.git/config）和全局配置文件（~/.gitconfig）

• 通過(guò)執(zhí)行如下命令，可以將用戶配置記錄到本地代碼倉(cāng)庫(kù)的配置文件中去

• git config user.name "demo"

• git config user.email "[email protected]"

?cat.git/config [core] repositoryformatversion=0 filemode=true bare=false logallrefupdates=true ignorecase=true precomposeunicode=true [user] name=demo [email protected].git/objects- 當(dāng)前代碼倉(cāng)庫(kù)代碼的存儲(chǔ)位置

• blob類型

• commit類型

• tree類型

#均無(wú)內(nèi)容 ?ll.git/objects total0 drwxr-xr-x2escapestaff64BNov2320:39info drwxr-xr-x2escapestaff64BNov2320:39pack ?ll.git/objects/info ?ll.git/objects/pack

.git/info- 當(dāng)前倉(cāng)庫(kù)的排除等信息

?cat./.git/info/exclude #gitls-files--others--exclude-from=.git/info/exclude #Linesthatstartwith'#'arecomments. #ForaprojectmostlyinC,thefollowingwouldbeagoodsetof #excludepatterns(uncommentthemifyouwanttousethem): #*.[oa] #*~.git/hooks- 當(dāng)前代碼倉(cāng)庫(kù)默認(rèn)鉤子腳本

./.git/hooks/commit-msg.sample ./.git/hooks/pre-rebase.sample ./.git/hooks/pre-commit.sample ./.git/hooks/applypatch-msg.sample ./.git/hooks/fsmonitor-watchman.sample ./.git/hooks/pre-receive.sample ./.git/hooks/prepare-commit-msg.sample ./.git/hooks/post-update.sample ./.git/hooks/pre-merge-commit.sample ./.git/hooks/pre-applypatch.sample ./.git/hooks/pre-push.sample ./.git/hooks/update.sample

.git/HEAD- 當(dāng)前代碼倉(cāng)庫(kù)的分支指針

?cat.git/HEAD ref:refs/heads/master

.git/refs- 當(dāng)前代碼倉(cāng)庫(kù)的頭指針

#均無(wú)內(nèi)容 ?ll.git/refs total0 drwxr-xr-x2escapestaff64BNov2320:39heads drwxr-xr-x2escapestaff64BNov2320:39tags ?ll.git/refs/heads ?ll.git/refs/tags

.git/description- 當(dāng)前代碼倉(cāng)庫(kù)的描述信息

?cat.git/description Unnamedrepository;editthisfile'description'tonametherepository.

add 之后發(fā)生了什么

執(zhí)行完成了 git add 命令，究竟做了什么呢？ 執(zhí)行完成如下命令之后，我們可以得到下圖所示的內(nèi)容，我們發(fā)現(xiàn)右側(cè)新增了一個(gè)文件，但是 Git 目錄里面的內(nèi)容絲毫沒(méi)有變化。這是因?yàn)?，我們現(xiàn)在執(zhí)行的修改默認(rèn)是放在工作區(qū)的，而工作區(qū)里面的修改不歸 Git 目錄去管理。 而當(dāng)我們執(zhí)行 git status 命令的時(shí)候，Git 又可以識(shí)別出來(lái)現(xiàn)在工作區(qū)新增了一個(gè)文件，這里怎么做到的呢？——詳見(jiàn)[理解 blob 對(duì)象和 SHA1]部分 而當(dāng)我們執(zhí)行 git add 命令讓 Git 幫助我們管理文件的時(shí)候，發(fā)現(xiàn)右側(cè)新增了一個(gè)目錄和兩個(gè)文件，分別是 8d 目錄、index 和0e41.. 文件。

#左邊執(zhí)行 $echo"hellogit">helle.txt $gitstatus $gitaddhello.txt #右邊執(zhí)行 $watch-n1-dfind.

我們這里重點(diǎn)看下，生成的 8d 這個(gè)目錄以及下面的文件。而其名稱的由來(lái)是因?yàn)?Git 對(duì)其進(jìn)行了一個(gè)叫做 SHA1 的 Hash 算法，用于將文件內(nèi)容或者字符串變成這么一串加密的字符。

#查看objects的文件類型 $gitcat-file-t8d0e41 blob #查看objects的文件內(nèi)容 $gitcat-file-p8d0e41 hellogit #查看objects的文件大小 $gitcat-file-s8d0e41 10 #拼裝起來(lái) blob10hellogit

現(xiàn)在我們就知道了，執(zhí)行 git add 命令將文件從工作區(qū)添加到暫存區(qū)里面，Git 會(huì)把幫助我們生成一些 Git 的對(duì)象，它存儲(chǔ)的是文件的內(nèi)容和文件類型并不存儲(chǔ)文件名稱。 為了驗(yàn)證我們上述的說(shuō)法，我們可以添加同樣的內(nèi)容到另一個(gè)文件，然后進(jìn)行提交，來(lái)觀察 .git 目錄的變化。我們發(fā)現(xiàn)，右側(cè)的 objects 目錄并沒(méi)有新增目錄和文件。這就可以證明，blob 類型的 object 只存儲(chǔ)的是文件的內(nèi)容，如果兩個(gè)文件的內(nèi)容一致的話，則只需要存儲(chǔ)一個(gè) object 即可。 話說(shuō)這里 object 為什么沒(méi)有存儲(chǔ)文件名稱呢？這里因?yàn)?SHA1 的 Hash 算法計(jì)算哈希的時(shí)候，本身就不包括文件名稱，所以取什么名稱都是無(wú)所謂的。那問(wèn)題來(lái)了，就是文件名的信息都存儲(chǔ)到哪里去了呢？——詳見(jiàn)[理解 blob 對(duì)象和 SHA1]部分

#左邊執(zhí)行 $echo"hellogit">tmp.txt $gitaddtmp.txt #右邊執(zhí)行 $watch-n1-dfind.

理解 blob 對(duì)象和 SHA1

了解 Git 的 blob 對(duì)象和 SHA1 之前的關(guān)系和對(duì)應(yīng)計(jì)算！ Hash 算法是把任意長(zhǎng)度的輸入通過(guò)散列算法變化成固定長(zhǎng)度的輸出，根據(jù)算法的不同，生成的長(zhǎng)度也有所不同。 Hash 算法：

• MD5-128bit- 不安全 - 文件校驗(yàn)

• SHA1-160bit(40位)- 不安全 -Git存儲(chǔ)

• SHA256-256bit- 安全 -Docker鏡像

• SHA512-512bit- 安全

但是，當(dāng)我們使用工具對(duì)上述文件內(nèi)容進(jìn)行 SHA1 計(jì)算的時(shí)候，會(huì)發(fā)現(xiàn)并沒(méi)有我們?cè)?.git 目錄里面看到的那樣，這是為什么呢？

?echo"hellogit"|shasum d6a96ae3b442218a91512b9e1c57b9578b487a0b-

這里因?yàn)?Git 工具的計(jì)算方式，是使用類型 長(zhǎng)度 內(nèi)容的方式進(jìn)行計(jì)算的。這里，我們算了下文件內(nèi)容只有九位，但是這里是十位，這里因?yàn)閮?nèi)容里面有換行符的存在導(dǎo)致的?，F(xiàn)在我們就可以使用 git cat-file 命令來(lái)拼裝 Git 工具存儲(chǔ)的完整內(nèi)容了。

?ls-lhhello.txt -rw-r--r--1escapestaff10BNov2321:12hello.txt ?echo"blob10hellogit"|shasum 8d0e41234f24b6da002d962a26c2495ea16a425f- #拼裝起來(lái) blob10hellogit

當(dāng)我們使用 cat 命令來(lái)查看 object 對(duì)象里面的內(nèi)容的時(shí)候，發(fā)現(xiàn)看著像是一串亂碼。其實(shí)這是 Git 工具將文件的原始內(nèi)容進(jìn)行一個(gè)壓縮，然后再存儲(chǔ)到 object 對(duì)象里面。奇怪的是，我們發(fā)現(xiàn)壓縮之后的內(nèi)容反而比原始內(nèi)容還大！ 這是因?yàn)槠溥M(jìn)行了壓縮，存儲(chǔ)了一些壓縮相關(guān)的信息。上例所示的比原始文件大，是因?yàn)槲覀儎?chuàng)建的內(nèi)容實(shí)在是太小了。當(dāng)我們常見(jiàn)一個(gè)比較大的文件時(shí)，就會(huì)看到壓縮之后的文件大小遠(yuǎn)小于原始文件的。

?cat.git/objects/8d/0e41234f24b6da002d962a26c2495ea16a425f xKOR04`HWH,6A% ?ls-lh.git/objects/8d/0e41234f24b6da002d962a26c2495ea16a425f -r--r--r--1escapestaff26BNov2321:36.git/objects/8d/0e41234f24b6da002d962a26c2495ea16a425f ?file.git/objects/8d/0e41234f24b6da002d962a26c2495ea16a425f .git/objects/8d/0e41234f24b6da002d962a26c2495ea16a425f:VAXCOFFexecutablenotstripped-version16694

其實(shí)，我們這里也是可以通過(guò) Python 代碼來(lái)獲取二進(jìn)制 object 對(duì)象的內(nèi)容的。

importzlib contents=open('0e41234f24b6da002d962a26c2495ea16a425f','rb').read() zlib.decompress(contents)

聊聊工作區(qū)和暫存區(qū)

聊聊工作區(qū)和暫存區(qū)，以及文件如何在工作區(qū)和緩存區(qū)之間同步的問(wèn)題。 之前的章節(jié)我們也聊到了，當(dāng)我們執(zhí)行 git status 命令的時(shí)候，Git 工具怎么知道我們有一個(gè)文件沒(méi)有追蹤，以及文件名的信息都存儲(chǔ)到哪里去了？ 這一切的答案，都要從工作區(qū)和索引區(qū)講起。Git 根據(jù)其存儲(chǔ)的狀態(tài)不同，將對(duì)應(yīng)狀態(tài)的“空間”分為工作區(qū)、暫存區(qū)（也可稱為索引區(qū)）和版本區(qū)三類。具體示例，可以參考下圖。

而更加深層次的理解，就要從執(zhí)行 git add 命令后生成相關(guān)的 object 對(duì)象，但是其存儲(chǔ)的是文件的類容、大小和內(nèi)容，并不包含文件名稱的信息。而文件名稱相關(guān)的信息就包含在生成的 index 文件（索引文件）里面。 當(dāng)我們直接查看 index 文件里面的內(nèi)容，發(fā)現(xiàn)使我們無(wú)法理解的亂碼，但是通過(guò)基本的輸出，我們可以看到其文件名稱。要想查看 index 文件的內(nèi)容，可以通過(guò) Git 提供的相關(guān)命令進(jìn)行查看。

#左邊執(zhí)行 $echo"file1">file1.txt $gitaddfile1.txt $cat.git/index $gitls-files#列出當(dāng)前暫存區(qū)的文件列表信息 $gitls-files-s#列出當(dāng)前暫存區(qū)文件的詳細(xì)信息 #右邊執(zhí)行 $watch-n1-dtree.git

當(dāng)添加文件的時(shí)候，文件或目錄會(huì)從工作區(qū)流向暫存區(qū)，加之一些其他操作，會(huì)導(dǎo)致工作區(qū)和暫存區(qū)是會(huì)有一定差別的。這就會(huì)導(dǎo)致，當(dāng)我們執(zhí)行 git status 的結(jié)果就是兩者的差別。 經(jīng)過(guò)如下操作，會(huì)使工作區(qū)和暫存區(qū)和的內(nèi)容不一致了，通過(guò)命令我們也是可以查看區(qū)別的。當(dāng)我們使用 add 命令將新文件添加到暫存區(qū)的時(shí)候，會(huì)發(fā)現(xiàn)這下就一致了。

#左邊執(zhí)行 $gitstatus $echo"file2">file2.txt $gitls-files-s $gitstatus $gitaddfile2.txt $gitls-files-s $gitstatus #右邊執(zhí)行 $watch-n1-dtree.git

如果我們這里去修改一個(gè)文件的話，很顯然這個(gè)時(shí)候我們的工作區(qū)和暫存區(qū)又不一致了。當(dāng)我們使用命令去查看文件狀態(tài)的時(shí)候，發(fā)現(xiàn)一個(gè)文件被修改了，而 Git 是怎么知道的呢？咳咳，就是通過(guò)查找 index 文件的內(nèi)容，找到對(duì)應(yīng)文件名稱以及其內(nèi)部引用的 object 對(duì)象，與工作區(qū)的文件內(nèi)容進(jìn)行對(duì)比而來(lái)的。

#左邊執(zhí)行 $gitls-files-s $echo"file.txt">file1.txt $gitstatus #右邊執(zhí)行 $watch-n1-dtree.git

而這個(gè)時(shí)候，我們?cè)偈褂?git add 命令將其修改內(nèi)容保存至?xí)捍鎱^(qū)的話，會(huì)發(fā)現(xiàn)對(duì)應(yīng)文件的 object 的 blob 對(duì)象的引用值發(fā)生改變了。這時(shí)可以發(fā)現(xiàn)，objects 目錄下面有三個(gè)對(duì)象了，其中 file1.txt 占了兩個(gè)，但是文件卻只有兩個(gè)。通過(guò)命令查看對(duì)應(yīng) blob 對(duì)象的內(nèi)容，發(fā)現(xiàn)各有不同。

#左邊執(zhí)行 $gitls-files-s $gitaddfile1.txt $gitls-files-s #右邊執(zhí)行 $watch-n1-dtree.git

理解 commit 提交原理

執(zhí)行完成了 git commit 命令，究竟做了什么呢？ Git 倉(cāng)庫(kù)中的提交記錄保存的是你的目錄下所有文件的快照，就像是把整個(gè)目錄復(fù)制，然后再粘貼一樣，但比復(fù)制粘貼優(yōu)雅許多！Git 希望提交記錄盡可能地輕量，因此在你每次進(jìn)行提交時(shí)，它并不會(huì)盲目地復(fù)制整個(gè)目錄。條件允許的情況下，它會(huì)將當(dāng)前版本與倉(cāng)庫(kù)中的上一個(gè)版本進(jìn)行對(duì)比，并把所有的差異打包到一起作為一個(gè)提交記錄。Git 還保存了提交的歷史記錄。這也是為什么大多數(shù)提交記錄的上面都有父節(jié)點(diǎn)的原因。 當(dāng)我們使用 add 命令將工作區(qū)提交到暫存區(qū)，而暫存區(qū)其實(shí)保存的是當(dāng)前文件的一個(gè)狀態(tài)，其中包括有哪些目錄和文件，以及其對(duì)應(yīng)的大小和內(nèi)容等信息。但是我們最終是需要將其提交到代碼倉(cāng)庫(kù)（本地）的，而其命令就是 git commit 了。

而當(dāng)我們執(zhí)行 git commit 命令的時(shí)候，究竟都發(fā)生了什么呢？可以看到當(dāng)提交之后，.git 目錄中生成了兩個(gè)信息的 object 對(duì)象，其中 logs 和 refs 目錄都有新的文件生成。通過(guò)如下操作，我們可以查看到其提交的類型和對(duì)應(yīng)內(nèi)容。

#左邊執(zhí)行 $gitcommit-m"1stcommit" $gitcat-file-t6e4a700#查看commit對(duì)象的類型 $gitcat-file-p6e4a700#查看commit對(duì)象的內(nèi)容 $gitcat-file-t64d6ef5#查看tree對(duì)象的類型 $gitcat-file-p64d6ef5#查看tree對(duì)象的內(nèi)容 #右邊執(zhí)行 $watch-n1-dtree.git

這樣我們就理解了，當(dāng)我們執(zhí)行 git commit 命令之后，會(huì)生成一個(gè) commit 對(duì)象和一個(gè) tree 對(duì)象。commit 對(duì)象內(nèi)容里面包含了一個(gè) tree 對(duì)象和相關(guān)提交信息，而 tree 對(duì)象里面則包含了這次我們提交版本里面的文件狀態(tài)（文件名稱和 blob 對(duì)象），這樣我們就知道了這次提交的變動(dòng)了。

我們這次提交之后，處理 objects 目錄發(fā)生變動(dòng)之外，還有一些其他的變化。比如 logs 和 refs 的目錄有所變化。我們查看 refs 目錄里面的內(nèi)容，發(fā)現(xiàn)其指向了 6e4a70這個(gè) commit 對(duì)象，即當(dāng)前 master 分支上面最新的提交就是這個(gè) 6e4a70了。 而這個(gè) 6e4a70這個(gè) commit 對(duì)象，有一個(gè) HEAD 的指向，就是 .git 目錄下的 HEAD 文件。其實(shí)質(zhì)就是一個(gè)指針，其永遠(yuǎn)指向我們當(dāng)前工作的分支，即這里我們工作在 master 分支上。當(dāng)我們切換分支的時(shí)候，這個(gè)文件的指向也會(huì)隨機(jī)改變的。

#左邊執(zhí)行 $cat.git/refs/heads/master $cat.git/HEAD #右邊執(zhí)行 $watch-n1-dtree.git

加深理解 commit 提交

執(zhí)行完成了 git commit 命令，究竟做了什么呢？ 當(dāng)我們?cè)俅螌?duì) file2.txt 文件的內(nèi)容進(jìn)行變更、添加以及提交之后，發(fā)現(xiàn)在提交的時(shí)候，查看的 commit 對(duì)象的內(nèi)容時(shí)，其包含有父節(jié)點(diǎn)的 commit 信息。而對(duì)于理解的話，可以看看下面的這個(gè)提交流程圖。

#左邊執(zhí)行 $echo"file2.txt">file2.txt $gitstatus $gitaddfile2.txt $gitls-files-s $gitcat-file-p0ac9638 $gitcommit-m"2ndcommit" $gitcat-file-pbab53ff $gitcat-file-p2f07720 #右邊執(zhí)行 $watch-n1-dtree.git

在 Git 中空文件夾是不算在追蹤范圍內(nèi)的，而且添加文件夾并不會(huì)增加 object 對(duì)象。當(dāng)我們查看 index 內(nèi)容的時(shí)候，會(huì)發(fā)現(xiàn)文件名稱是包含相對(duì)路徑的。 而當(dāng)我們通過(guò) commit 命令提交之后，會(huì)發(fā)現(xiàn)生成了三個(gè) object 對(duì)象，因?yàn)?commit 操作不會(huì)生成 blob 對(duì)象，所以分別是一個(gè) commit 對(duì)象和兩個(gè) tree 對(duì)象?？梢园l(fā)現(xiàn)，tree 對(duì)象里面有包含了一個(gè)目錄的 tree，其里面包含對(duì)象文件內(nèi)容。 下圖所示的文件狀態(tài)，可以體會(huì)到 Git 中版本的概念。即 commit 對(duì)象指向一個(gè)該版本中的文件目錄樹(shù)的根（tree），然后 tree 在指向 blob 對(duì)象（文件）和 tree 對(duì)象（目錄），這樣就可以無(wú)限的往復(fù)下去形成一個(gè)完整的版本。

#左邊執(zhí)行 $mkdirfloder1 $echo"file3">floder1/file3.txt $gitaddfloder1 $gitls-files-s $gitcommit-m"3rdcommit" $gitcat-file-p1711e01 $gitcat-file-p9ab67f8 #右邊執(zhí)行 $watch-n1-dtree.git

文件的生命周期狀態(tài)

總結(jié)一下，Git 里面的文件狀態(tài)和如何切換。 現(xiàn)在，我們已經(jīng)基本理解了文件如何在工作區(qū)、暫存區(qū)以及代碼倉(cāng)庫(kù)之間進(jìn)行狀態(tài)的跟蹤和同步。在 Git 的操作中，文件的可能狀態(tài)有哪些，以及如何進(jìn)行狀態(tài)切換的，我們這里一起總結(jié)一下！

Branch 和 HEAD 的意義

執(zhí)行完成了 git branch 命令，究竟做了什么呢？ 到底什么是分支？分支切換又是怎么一回事？我們通過(guò)查看 Git 的官方文檔，就可以得到，分支就是一個(gè)有名字的（master/dev）指向 commit 對(duì)象的一個(gè)指針。 我們?cè)诔跏蓟瘋}(cāng)庫(kù)的時(shí)候，提供會(huì)默認(rèn)給我們分配一個(gè)叫做 master 的分支（在最新的版本默認(rèn)倉(cāng)庫(kù)已經(jīng)變更為 main 了），而 master 分支就是指向最新的一次提交。為什么需要給分支起名字呢？就是為了方便我們使用和記憶，可以簡(jiǎn)單理解為 alias 命令的意義一致。

有了上述基礎(chǔ)，我們就需要考慮下，分支到底是如何實(shí)現(xiàn)和工作的。要實(shí)現(xiàn)一個(gè)分支，我們最基本需要解決兩個(gè)問(wèn)題，第一個(gè)就是需要存儲(chǔ)每一個(gè)分支指向的 commit，第二個(gè)問(wèn)題就是在切換分支的時(shí)候幫助我們標(biāo)識(shí)當(dāng)前分支。 在 Git 中，它有一個(gè)非常特殊的 HEAD 文件。而 HEAD 文件是一個(gè)指針，其有一個(gè)特性就是總會(huì)指向當(dāng)前分支的最新的一個(gè) commit 對(duì)象。而這個(gè) HEAD 文件正好，解決了我們上面提出的兩個(gè)問(wèn)題。 當(dāng)我們從 master 切換分支到 dev 的時(shí)候，HEAD 文件也會(huì)隨即切換，即指向 dev 這個(gè)指針。設(shè)計(jì)就是這么美麗，不愧是鬼才，好腦袋。

#左邊執(zhí)行 $cat.git/HEAD $cat.git/refs/heads/master $gitcat-file-t1711e01 #右邊執(zhí)行 $glo=gitlog

分支操作的背后邏輯

執(zhí)行完成了 git branch 命令，究竟做了什么呢？ 這里我們可以看到分支切換之后，HEAD 指向發(fā)生變動(dòng)了。

#左邊執(zhí)行 $gitbranch $gitbranchdev $ll.git/refs/heads $cat.git/refs/heads/master $cat.git/refs/heads/dev $cat.git/HEAD $gitcheckoutdev $cat.git/HEAD #右邊執(zhí)行 $glo=gitlog

這里需要注意的是，即使我們刪除了分支，但是該分支上一些特有的對(duì)象并不會(huì)被刪除的。這些對(duì)象其實(shí)就是我們俗稱的垃圾對(duì)象，還有我們多次使用 add 命令所產(chǎn)生的也有垃圾對(duì)象，而這些垃圾對(duì)象怎么清除和回收呢？后續(xù)，我們會(huì)涉及到的。

#左邊執(zhí)行 $echo"dev">dev.txt $gitadddev.txt $gitcommit-m"1stcommitfromdevbranch" $gitcheckoutmaster $gitbranch-ddev $gitbranch-Ddev $gitcat-file-t861832c $gitcat-file-p861832c $gitcat-file-p680f6e9 $gitcat-file-p38f8e88 #右邊執(zhí)行 $glo=gitlog

checkout 和 commit 操作

我們一起聊一聊，checkout 和 commit 的操作！ 我們執(zhí)行 checkout 命令的時(shí)候，其不光可以切換分支，而且可以切換到指定的 commit 上面，即 HEAD 文件會(huì)指向某個(gè) commit 對(duì)象。在 Git 里面，將 HEAD 文件沒(méi)有指向 master 的這個(gè)現(xiàn)象稱之為 detached HEAD。 這里不管 HEAD 文件指向的是分支名稱也好，是 commit 對(duì)象也罷，其實(shí)本質(zhì)都是一樣的，因?yàn)榉种Q也是指向某個(gè) commit 對(duì)象的。

#左邊執(zhí)行 $gitcheckout6e4a700 $gitlog #右邊執(zhí)行 $glo=gitlog

當(dāng)我們切換到指定的 commit 的時(shí)候，如果需要在對(duì)應(yīng)的 commit 上繼續(xù)修改代碼提交的話，可以使用上述圖片中提及的 swtich 命令創(chuàng)建新分支，再進(jìn)行提交。但是，通常我們都不會(huì)著玩，都會(huì)使用 checkout 命令來(lái)創(chuàng)建新分支的。

$gitcheckout-btmp $gitlog

即使可以這樣操作，我們也很少使用。還記得我們上一章節(jié)創(chuàng)建的 dev 分支嗎？我們創(chuàng)建了該分支并有了一個(gè)新的提交，但是沒(méi)有合并到 master 分支就直接刪除了?，F(xiàn)在再使用 log 命令查看的話，是看不到了。 實(shí)際，真的看不到了嗎？大家要記住，在 Git 里面任何的操作，比如分支的刪除。它只是刪除了指向某個(gè)特定 commit 的指針引用而已，而那個(gè) commit 本身并不會(huì)被刪除，即 dev 分支的那個(gè) commit 提交還是在的。 那我們?cè)趺凑业竭@個(gè) commit 呢？找到之后，我們就可以在上面繼續(xù)工作，或者找到之前的文件數(shù)據(jù)等。 第一種方法：

• [費(fèi)勁不太好，下下策]

• 在 objects 目錄下面，自己一個(gè)一個(gè)看，然后切換過(guò)去。

第二種方法：

• [推薦的操作方式]

• 使用 Git 提供的 git reflog 專用命令來(lái)查找。

• 該命令的作用就是用于將我們之前的所有操作都記錄下來(lái)。

#左邊執(zhí)行 $gitreflog $gitcheckout9fb7a14 $gitcheckout-bdev #右邊執(zhí)行 $glo=gitlog

聊聊 diff 的執(zhí)行邏輯

當(dāng)我們執(zhí)行 diff 命令之后，Git 的邏輯它們是怎么對(duì)比出來(lái)的呢？ 就在本節(jié)中中，我們使用上節(jié)的倉(cāng)庫(kù)，修改文件內(nèi)容之后，看看 diff 命令都輸出了哪些內(nèi)容呢？我們這里一起來(lái)看看，研究研究！

$echo"hello">file1.txt $gitdiff $gitcat-file-p42d9955 $gitcat-file-pce01362 #下述命令原理也是一樣的 $gitdiff--cached $gitdiffHEAD

Git 如何添加遠(yuǎn)程倉(cāng)庫(kù)

如何將我們本地的倉(cāng)庫(kù)和遠(yuǎn)程服務(wù)器上面的倉(cāng)庫(kù)關(guān)聯(lián)起來(lái)呢？ 初始化倉(cāng)庫(kù)

$gitinit $gitaddREADME.md $gitcommit-m"firstcommit"

關(guān)聯(lián)遠(yuǎn)程倉(cāng)庫(kù) 當(dāng)我們使用上述命令來(lái)關(guān)聯(lián)遠(yuǎn)程服務(wù)器倉(cāng)庫(kù)的時(shí)候，我們本地 .git 目錄也是會(huì)發(fā)生改變的。通過(guò)命令查看 .git/config 文件的話，可以看到配置文件中出現(xiàn)了[remote]字段。

#關(guān)聯(lián)遠(yuǎn)程倉(cāng)庫(kù) [email protected]:escapelife/git-demo.git

?cat.git/config [core] repositoryformatversion=0 filemode=true bare=false logallrefupdates=true ignorecase=true precomposeunicode=true [remote"origin"] [email protected]:escapelife/git-demo.git fetch=+refs/heads/*:refs/remotes/origin/*

推送本地分支 當(dāng)我們執(zhí)行如下命令，將本地 master 分支推送到遠(yuǎn)程 origin 倉(cāng)庫(kù)的 master 分支。之后，我們登陸 GitHub 就可以看到推送的文件及目錄內(nèi)容了。 推送分支內(nèi)容的時(shí)候，會(huì)列舉推送的 objects 數(shù)量，并將其內(nèi)容進(jìn)行壓縮，之后推送到我們遠(yuǎn)程的 GitHub 倉(cāng)庫(kù)，并且創(chuàng)建了一個(gè)遠(yuǎn)程的 master 分支（origin 倉(cāng)庫(kù)）。

#推送本地分支 $gitpush-uoriginmaster

推送之后，我們可以發(fā)現(xiàn)，本地的 .git 生成了一些文件和目錄，它們都是什么呢？如下所示，會(huì)新增四個(gè)目錄和兩個(gè)文件，皆為遠(yuǎn)程倉(cāng)庫(kù)的信息。當(dāng)我們通過(guò)命令查看 master 這個(gè)文件的內(nèi)容時(shí)，會(huì)發(fā)現(xiàn)其也是一個(gè) commit 對(duì)象。此時(shí)與我們本地 master 分支所指向的一致。而其用于表示遠(yuǎn)程倉(cāng)庫(kù)的當(dāng)前版本，用于和本地進(jìn)行區(qū)別和校對(duì)的。

?tree.git ├──logs │├──HEAD │└──refs │├──heads ││├──dev ││├──master ││└──tmp │└──remotes#新增目錄 │└──origin#新增目錄 │└──master#新增文件 └──refs ├──heads │├──dev │├──master │└──tmp ├──remotes#新增目錄 │└──origin#新增目錄 │└──master#新增文件 └──tags

遠(yuǎn)程倉(cāng)庫(kù)存儲(chǔ)代碼

使用 GitLab 來(lái)了解遠(yuǎn)程倉(cāng)庫(kù)的服務(wù)器到底是如何存儲(chǔ)，我們的代碼的！ 當(dāng)我們編寫(xiě)完代碼之后，將其提交到對(duì)應(yīng)的遠(yuǎn)程服務(wù)器上面，其存儲(chǔ)結(jié)構(gòu)和我們地址是一模一樣的。如果我們仔細(xì)想想的話，不一樣的話才見(jiàn)怪了。 Git 本來(lái)就是代碼的分發(fā)平臺(tái)，無(wú)中心節(jié)點(diǎn)，即每個(gè)節(jié)點(diǎn)都是主節(jié)點(diǎn)，所以其存儲(chǔ)的目錄結(jié)構(gòu)都是一直的。這樣，不管哪一個(gè)節(jié)點(diǎn)的內(nèi)容發(fā)生丟失或缺失的話，我們都可以通過(guò)其他節(jié)點(diǎn)來(lái)找到。而 Git 服務(wù)器就是一個(gè)可以幫助我們，實(shí)時(shí)都可以找到的節(jié)點(diǎn)，而已。 原文鏈接：https://www.escapelife.site/posts/da89563c.html