加深理解 commit 提交

執行完成了 git commit 命令，究竟做了什么呢？

當我們再次對 file2.txt 文件的內容進行變更、添加以及提交之后，發現在提交的時候，查看的 commit 對象的內容時，其包含有父節點的 commit 信息。而對于理解的話，可以看看下面的這個提交流程圖。

# 左邊執行
$ echo "file2.txt" > file2.txt
$ git status
$ git add file2.txt
$ git ls-files -s
$ git cat-file -p 0ac9638
$ git commit -m "2nd commit"
$ git cat-file -p bab53ff
$ git cat-file -p 2f07720

# 右邊執行
$ watch -n 1 -d tree .git

在 Git 中空文件夾是不算在追蹤范圍內的，而且添加文件夾并不會增加 object 對象。當我們查看 index 內容的時候，會發現文件名稱是包含相對路徑的。

而當我們通過 commit 命令提交之后，會發現生成了三個 object 對象，因為 commit 操作不會生成 blob 對象，所以分別是一個 commit 對象和兩個 tree 對象。可以發現，tree 對象里面有包含了一個目錄的 tree，其里面包含對象文件內容。

下圖所示的文件狀態，可以體會到 Git 中版本的概念。即 commit 對象指向一個該版本中的文件目錄樹的根（tree），然后 tree 在指向 blob 對象（文件）和 tree 對象（目錄），這樣就可以無限的往復下去形成一個完整的版本。

# 左邊執行
$ mkdir floder1
$ echo "file3" > floder1/file3.txt
$ git add floder1
$ git ls-files -s
$ git commit -m "3rd commit"
$ git cat-file -p 1711e01
$ git cat-file -p 9ab67f8

# 右邊執行
$ watch -n 1 -d tree .git

文件的生命周期狀態

總結一下，Git 里面的文件狀態和如何切換。

現在，我們已經基本理解了文件如何在工作區、暫存區以及代碼倉庫之間進行狀態的跟蹤和同步。在 Git 的操作中，文件的可能狀態有哪些，以及如何進行狀態切換的，我們這里一起總結一下！

Branch 和 HEAD 的意義

執行完成了 git branch 命令，究竟做了什么呢？

到底什么是分支？分支切換又是怎么一回事？我們通過查看 Git 的官方文檔，就可以得到，分支就是一個有名字的（master/dev）指向 commit 對象的一個指針。

我們在初始化倉庫的時候，提供會默認給我們分配一個叫做 master 的分支（在最新的版本默認倉庫已經變更為 main 了），而 master 分支就是指向最新的一次提交。為什么需要給分支起名字呢？就是為了方便我們使用和記憶，可以簡單理解為 alias 命令的意義一致。

有了上述基礎，我們就需要考慮下，分支到底是如何實現和工作的。要實現一個分支，我們最基本需要解決兩個問題，第一個就是需要存儲每一個分支指向的 commit，第二個問題就是在切換分支的時候幫助我們標識當前分支。

在 Git 中，它有一個非常特殊的 HEAD 文件。而 HEAD 文件是一個指針，其有一個特性就是總會指向當前分支的最新的一個 commit 對象。而這個 HEAD 文件正好，解決了我們上面提出的兩個問題。

當我們從 master 切換分支到 dev 的時候，HEAD 文件也會隨即切換，即指向 dev 這個指針。設計就是這么美麗，不愧是鬼才，好腦袋。

# 左邊執行
$ cat .git/HEAD
$ cat .git/refs/heads/master
$ git cat-file -t 1711e01

# 右邊執行
$ glo = git log

分支操作的背后邏輯

執行完成了 git branch 命令，究竟做了什么呢？

這里我們可以看到分支切換之后，HEAD 指向發生變動了。

# 左邊執行
$ git branch
$ git branch dev
$ ll .git/refs/heads
$ cat .git/refs/heads/master
$ cat .git/refs/heads/dev
$ cat .git/HEAD
$ git checkout dev
$ cat .git/HEAD

# 右邊執行
$ glo = git log

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

# 左邊執行
$ echo "dev" > dev.txt
$ git add dev.txt
$ git commit -m "1st commit from dev branch"
$ git checkout master
$ git branch -d dev
$ git branch -D dev
$ git cat-file -t 861832c
$ git cat-file -p 861832c
$ git cat-file -p 680f6e9
$ git cat-file -p 38f8e88

# 右邊執行
$ glo = git log

checkout 和 commit 操作

我們一起聊一聊，checkout 和 commit 的操作！

我們執行 checkout 命令的時候，其不光可以切換分支，而且可以切換到指定的 commit 上面，即 HEAD 文件會指向某個 commit 對象。在 Git 里面，將 HEAD 文件沒有指向 master 的這個現象稱之為 detached HEAD。

這里不管 HEAD 文件指向的是分支名稱也好，是 commit 對象也罷，其實本質都是一樣的，因為分支名稱也是指向某個 commit 對象的。

# 左邊執行
$ git checkout 6e4a700
$ git log

# 右邊執行
$ glo = git log

當我們切換到指定的 commit 的時候，如果需要在對應的 commit 上繼續修改代碼提交的話，可以使用上述圖片中提及的 swtich 命令創建新分支，再進行提交。但是，通常我們都不會著玩，都會使用 checkout 命令來創建新分支的。

$ git checkout -b tmp
$ git log

即使可以這樣操作，我們也很少使用。還記得我們上一章節創建的 dev 分支嗎？我們創建了該分支并有了一個新的提交，但是沒有合并到 master 分支就直接刪除了。現在再使用 log 命令查看的話，是看不到了。

實際，真的看不到了嗎？大家要記住，在 Git 里面任何的操作，比如分支的刪除。它只是刪除了指向某個特定 commit 的指針引用而已，而那個 commit 本身并不會被刪除，即 dev 分支的那個 commit 提交還是在的。

那我們怎么找到這個 commit 呢？找到之后，我們就可以在上面繼續工作，或者找到之前的文件數據等。

第一種方法：

• [費勁不太好，下下策]
• 在 objects 目錄下面，自己一個一個看，然后切換過去。

第二種方法：

• [推薦的操作方式]
• 使用 Git 提供的 git reflog 專用命令來查找。
• 該命令的作用就是用于將我們之前的所有操作都記錄下來。

# 左邊執行
$ git reflog
$ git checkout 9fb7a14
$ git checkout -b dev

# 右邊執行
$ glo = git log

聊聊 diff 的執行邏輯

當我們執行 diff 命令之后，Git 的邏輯它們是怎么對比出來的呢？

就在本節中中，我們使用上節的倉庫，修改文件內容之后，看看 diff 命令都輸出了哪些內容呢？我們這里一起來看看，研究研究！

$ echo "hello" > file1.txt
$ git diff
$ git cat-file -p 42d9955
$ git cat-file -p ce01362

# 下述命令原理也是一樣的
$ git diff --cached
$ git diff HEAD

Git 如何添加遠程倉庫

如何將我們本地的倉庫和遠程服務器上面的倉庫關聯起來呢？

初始化倉庫

$ git init
$ git add README.md
$ git commit -m "first commit"

關聯遠程倉庫

當我們使用上述命令來關聯遠程服務器倉庫的時候，我們本地 .git 目錄也是會發生改變的。通過命令查看 .git/config 文件的話，可以看到配置文件中出現了 [remote] 字段。

# 關聯遠程倉庫
$ git remote add origin git@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/*

推送本地分支

當我們執行如下命令，將本地 master 分支推送到遠程 origin 倉庫的 master 分支。之后，我們登陸 GitHub 就可以看到推送的文件及目錄內容了。

推送分支內容的時候，會列舉推送的 objects 數量，并將其內容進行壓縮，之后推送到我們遠程的 GitHub 倉庫，并且創建了一個遠程的 master 分支（origin 倉庫）。

# 推送本地分支
$ git push -u origin master

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

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

遠程倉庫存儲代碼

使用 GitLab 來了解遠程倉庫的服務器到底是如何存儲，我們的代碼的！

當我們編寫完代碼之后，將其提交到對應的遠程服務器上面，其存儲結構和我們地址是一模一樣的。如果我們仔細想想的話，不一樣的話才見怪了。

Git 本來就是代碼的分發平臺，無中心節點，即每個節點都是主節點，所以其存儲的目錄結構都是一直的。這樣，不管哪一個節點的內容發生丟失或缺失的話，我們都可以通過其他節點來找到。而 Git 服務器就是一個可以幫助我們，實時都可以找到的節點而已。