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

Git 初始化代碼倉庫

執(zhí)行完成了 git init 命令，究竟做了什么呢？ 執(zhí)行完成如下命令之后，我們可以得到下圖所示的內(nèi)容，右側(cè)的就是 Git 為我們創(chuàng)建的代碼倉庫，其中包含了用于版本管理所需要的內(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)前代碼倉庫本地的配置文件

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

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

• git config user.name "demo"

• git config user.email "demo@demo.com"

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

• blob類型

• commit類型

• tree類型

#均無內(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)前倉庫的排除等信息

?cat./.git/info/exclude #gitls-files--others--exclude-from=.git/info/exclude #Linesthatstartwith'#'arecomments. #ForaprojectmostlyinC,thefollowingwouldbeagoodsetof #excludepatterns(uncommentthemifyouwanttousethem): #*.[oa] #*~.git/hooks- 當(dāng)前代碼倉庫默認(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)前代碼倉庫的分支指針

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

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

#均無內(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)前代碼倉庫的描述信息

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

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

執(zhí)行完成了 git add 命令，究竟做了什么呢？ 執(zhí)行完成如下命令之后，我們可以得到下圖所示的內(nèi)容，我們發(fā)現(xiàn)右側(cè)新增了一個(gè)文件，但是 Git 目錄里面的內(nèi)容絲毫沒有變化。這是因?yàn)椋覀儸F(xiàn)在執(zhí)行的修改默認(rèn)是放在工作區(qū)的，而工作區(qū)里面的修改不歸 Git 目錄去管理。 而當(dāng)我們執(zhí)行 git status 命令的時(shí)候，Git 又可以識別出來現(xiàn)在工作區(qū)新增了一個(gè)文件，這里怎么做到的呢？——詳見[理解 blob 對象和 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è)目錄以及下面的文件。而其名稱的由來是因?yàn)?Git 對其進(jìn)行了一個(gè)叫做 SHA1 的 Hash 算法，用于將文件內(nèi)容或者字符串變成這么一串加密的字符。

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

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

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

理解 blob 對象和 SHA1

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

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

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

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

• SHA512-512bit- 安全

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

?echo"hellogit"|shasum d6a96ae3b442218a91512b9e1c57b9578b487a0b-

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

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

當(dāng)我們使用 cat 命令來查看 object 對象里面的內(nèi)容的時(shí)候，發(fā)現(xiàn)看著像是一串亂碼。其實(shí)這是 Git 工具將文件的原始內(nèi)容進(jìn)行一個(gè)壓縮，然后再存儲到 object 對象里面。奇怪的是，我們發(fā)現(xiàn)壓縮之后的內(nèi)容反而比原始內(nèi)容還大！ 這是因?yàn)槠溥M(jìn)行了壓縮，存儲了一些壓縮相關(guān)的信息。上例所示的比原始文件大，是因?yàn)槲覀儎?chuàng)建的內(nèi)容實(shí)在是太小了。當(dāng)我們常見一個(gè)比較大的文件時(shí)，就會看到壓縮之后的文件大小遠(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í)，我們這里也是可以通過 Python 代碼來獲取二進(jìn)制 object 對象的內(nèi)容的。

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

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

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

而更加深層次的理解，就要從執(zhí)行 git add 命令后生成相關(guān)的 object 對象，但是其存儲的是文件的類容、大小和內(nèi)容，并不包含文件名稱的信息。而文件名稱相關(guān)的信息就包含在生成的 index 文件（索引文件）里面。 當(dāng)我們直接查看 index 文件里面的內(nèi)容，發(fā)現(xiàn)使我們無法理解的亂碼，但是通過基本的輸出，我們可以看到其文件名稱。要想查看 index 文件的內(nèi)容，可以通過 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í)候，文件或目錄會從工作區(qū)流向暫存區(qū)，加之一些其他操作，會導(dǎo)致工作區(qū)和暫存區(qū)是會有一定差別的。這就會導(dǎo)致，當(dāng)我們執(zhí)行 git status 的結(jié)果就是兩者的差別。 經(jīng)過如下操作，會使工作區(qū)和暫存區(qū)和的內(nèi)容不一致了，通過命令我們也是可以查看區(qū)別的。當(dāng)我們使用 add 命令將新文件添加到暫存區(qū)的時(shí)候，會發(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 是怎么知道的呢？咳咳，就是通過查找 index 文件的內(nèi)容，找到對應(yīng)文件名稱以及其內(nèi)部引用的 object 對象，與工作區(qū)的文件內(nèi)容進(jìn)行對比而來的。

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

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

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

理解 commit 提交原理

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

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

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

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

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

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

加深理解 commit 提交

執(zhí)行完成了 git commit 命令，究竟做了什么呢？ 當(dāng)我們再次對 file2.txt 文件的內(nèi)容進(jìn)行變更、添加以及提交之后，發(fā)現(xiàn)在提交的時(shí)候，查看的 commit 對象的內(nèi)容時(shí)，其包含有父節(jié)點(diǎn)的 commit 信息。而對于理解的話，可以看看下面的這個(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)的，而且添加文件夾并不會增加 object 對象。當(dāng)我們查看 index 內(nèi)容的時(shí)候，會發(fā)現(xiàn)文件名稱是包含相對路徑的。 而當(dāng)我們通過 commit 命令提交之后，會發(fā)現(xiàn)生成了三個(gè) object 對象，因?yàn)?commit 操作不會生成 blob 對象，所以分別是一個(gè) commit 對象和兩個(gè) tree 對象。可以發(fā)現(xiàn)，tree 對象里面有包含了一個(gè)目錄的 tree，其里面包含對象文件內(nèi)容。 下圖所示的文件狀態(tài)，可以體會到 Git 中版本的概念。即 commit 對象指向一個(gè)該版本中的文件目錄樹的根（tree），然后 tree 在指向 blob 對象（文件）和 tree 對象（目錄），這樣就可以無限的往復(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ū)以及代碼倉庫之間進(jìn)行狀態(tài)的跟蹤和同步。在 Git 的操作中，文件的可能狀態(tài)有哪些，以及如何進(jìn)行狀態(tài)切換的，我們這里一起總結(jié)一下！

Branch 和 HEAD 的意義

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

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

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

#左邊執(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 文件會指向某個(gè) commit 對象。在 Git 里面，將 HEAD 文件沒有指向 master 的這個(gè)現(xiàn)象稱之為 detached HEAD。 這里不管 HEAD 文件指向的是分支名稱也好，是 commit 對象也罷，其實(shí)本質(zhì)都是一樣的，因?yàn)榉种Q也是指向某個(gè) commit 對象的。

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

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

$gitcheckout-btmp $gitlog

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

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

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

第二種方法：

• [推薦的操作方式]

• 使用 Git 提供的 git reflog 專用命令來查找。

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

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

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

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

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

Git 如何添加遠(yuǎn)程倉庫

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

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

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

#關(guān)聯(lián)遠(yuǎn)程倉庫 $gitremoteaddorigingit@github.com:escapelife/git-demo.git

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

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

#推送本地分支 $gitpush-uoriginmaster

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

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

遠(yuǎn)程倉庫存儲代碼

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