前言

作為一個(gè)新時(shí)代的開發(fā)者，想必大家在工作中，有一樣?xùn)|西是和大家「形影不離」的。那就是git。(當(dāng)然，這里也有個(gè)例，如果大家項(xiàng)目還停留在svn階段，就算我剛才的話唐突了)。

無論大家平時(shí)是喜歡在命令行中手搓git命令，還是利用git可視化工具(SourceTree)進(jìn)行代碼管理。終究都逃不過，add/commit/merge/push等命令的支配。所以，今天我們來聊聊，在進(jìn)行這些命令的時(shí)候，在最底層到底發(fā)生了啥。

還有一點(diǎn)，也算是一個(gè)認(rèn)知提升吧。需要和大家嘮叨一下，以后遇到比較棘手的問題，可以往這方面來靠攏

所有軟件的底層實(shí)現(xiàn)都是「操作和管理數(shù)據(jù)」。

無論是我們平時(shí)用到的桌面程序，亦或是在命令行中進(jìn)行敲敲打打處理一些特定的操作，還有就是我們熟悉的編程開發(fā)中，無論是前端的開發(fā)過程中，使用原生也好，各種框架也罷，最后的根結(jié)都是數(shù)據(jù)的羅列和排布;還是后端就更明顯了，有SQL的操作，那就更是再「玩弄」數(shù)據(jù)。 之所以我們看到的現(xiàn)象有些不同，無非就是數(shù)據(jù)的表現(xiàn)形式和處理方式的不同。可以說，在編程界，--「萬物皆數(shù)據(jù)」。

這里簡(jiǎn)單舉一個(gè)例子，日歷大家都見過哇。

如果，給我們一個(gè)需求，要讓我們實(shí)現(xiàn)一個(gè)飛書日歷或者google 日歷的開發(fā)任務(wù)，我們是不是一時(shí)感覺到無法下手。

那我們往「萬物皆數(shù)據(jù)」這個(gè)定論上靠，那是不是每一個(gè)「日程」（無論是簡(jiǎn)單日程還是重復(fù)日程），它們本質(zhì)上就是在每個(gè)小格子上展示。無非就是有的日程在單個(gè)格子上，有的日程是跨格子。 而針對(duì)這種情況，是不是就是在當(dāng)前視圖中，我們需要維護(hù)一個(gè)數(shù)組，而這個(gè)數(shù)組中的項(xiàng)就是每個(gè)格子的示例。(針對(duì)月視圖/周視圖/日視圖的數(shù)據(jù)，其實(shí)都是一套，只不過在框架內(nèi)部為我們提供了各自的展示邏輯)

這是一個(gè)開源的日歷庫(FullCalendar)。

圖片

而下面的events就是我們?cè)谌諝v上顯示的日程信息。

圖片

好了，天不早了，干點(diǎn)正事哇。

我們能所學(xué)到的知識(shí)點(diǎn)

1. 前置知識(shí)點(diǎn)
2. git init
3. 新增一個(gè)文件
4. git commit
5. 新增修改
6. 創(chuàng)建分支
7. 分支切換
8. 分支合并
9. 遠(yuǎn)程提交

1. 前置知識(shí)點(diǎn)

「前置知識(shí)點(diǎn)」，只是做一個(gè)概念的介紹，不會(huì)做深度解釋。因?yàn)?，這些概念在下面文章中會(huì)有出現(xiàn)，為了讓行文更加的順暢，所以將本該在文內(nèi)的概念解釋放到前面來?！溉绻蠹覍?duì)這些概念熟悉，可以直接忽略」同時(shí)，由于閱讀我文章的群體有很多，所以有些知識(shí)點(diǎn)可能「我視之若珍寶，爾視只如草芥，棄之如敝履」。以下知識(shí)點(diǎn)，請(qǐng)「酌情使用」。

什么是git

Git是一種用于源代碼管理的工具。它是一個(gè)免費(fèi)且開源的版本控制系統(tǒng)，用于高效地處理從小型到非常大型的項(xiàng)目。Git用于跟蹤源代碼的更改，使多個(gè)開發(fā)人員能夠共同在非線性開發(fā)中合作。Git是由Linus Torvalds于2005年為L(zhǎng)inux內(nèi)核的開發(fā)而創(chuàng)建的。

集中式管理

在使用Git之前在維護(hù)代碼之前，團(tuán)隊(duì)合作的模式如下：

• 開發(fā)人員過去會(huì)將他們的代碼提交到「中央服務(wù)器」，而沒有自己的副本。
• 對(duì)源代碼所做的任何更改對(duì)其他開發(fā)人員來說都是「未知的」。
• 沒有任何開發(fā)人員之間的溝通。

圖片

它的典型代表為SVN

分布式管理

• 每個(gè)開發(fā)人員都在其本地系統(tǒng)上擁有「完整的代碼副本」。
• 對(duì)源代碼所做的任何更改都可以「被其他人跟蹤」。
• 開發(fā)人員之間有定期的溝通。

圖片

毋庸置疑，git是這方面的王者。

git基礎(chǔ)概念

• workspace：是本地項(xiàng)目的工作目錄，屬于「本地代碼發(fā)生更新但尚未執(zhí)行 git add 命令時(shí)的狀態(tài)」，working tree的狀態(tài)也隨之更新
• index：是索引文件，它是連接working tree和commit的橋梁，每當(dāng)我們使用git add命令來登記后，index file的內(nèi)容就會(huì)改變，此時(shí)index file就和working tree同步了。

• 它還有一個(gè)家喻戶曉的名字 -「暫存區(qū)」

• local repository：是「本地倉庫」，當(dāng)我們使用git commit命令提交最新代碼時(shí)，代碼才真正進(jìn)入git倉庫。

• git commit -m “xxx” 就是「將 index 里的內(nèi)容提交到本地倉庫中」

• remote repository：是「遠(yuǎn)程倉庫」，當(dāng)我們使用git push命令時(shí)就會(huì)將本地倉庫的代碼上傳至遠(yuǎn)程倉庫，完成整個(gè)代碼的上傳工作

圖片

git init --bare VS git init

git init --bare 和 git init 是兩種不同的Git初始化命令，它們用于創(chuàng)建不同類型的Git倉庫。

下面是它們之間的主要區(qū)別：

1. 「?jìng)}庫類型」:

• git init: 這個(gè)命令用于創(chuàng)建一個(gè)「標(biāo)準(zhǔn)的Git工作目錄倉庫」。它會(huì)在當(dāng)前目錄下創(chuàng)建一個(gè).git子目錄，其中「包含Git的版本控制文件和歷史記錄」（這是我們這篇文章的重點(diǎn)）。這種類型的倉庫通常用于開發(fā)和維護(hù)代碼。
• git init --bare: 這個(gè)命令用于創(chuàng)建一個(gè)"裸"（bare）倉庫，它不包含工作目錄。這意味著它只包含Git版本控制的文件和歷史記錄，「沒有實(shí)際的項(xiàng)目文件」。"裸"倉庫通常用作「中央版本庫」，用于協(xié)作和共享代碼。

2. 「默認(rèn)分支」:

• git init 默認(rèn)創(chuàng)建一個(gè)帶有master分支的工作目錄倉庫。

• git init --bare 默認(rèn)不創(chuàng)建分支，因?yàn)槁銈}庫不包含工作目錄。我們需要手動(dòng)創(chuàng)建和設(shè)置分支。

一般情況下，如果我們需要?jiǎng)?chuàng)建一個(gè)新的Git倉庫用于開發(fā)和維護(hù)代碼，我們應(yīng)該使用 git init。如果我們需要?jiǎng)?chuàng)建一個(gè)中央版本庫用于團(tuán)隊(duì)協(xié)作和共享代碼，我們可以考慮使用 git init --bare。

Hook

鉤子（Hooks）是一種通用概念，通常用于「在特定事件發(fā)生時(shí)觸發(fā)自定義代碼」。雖然不是編程語言本身的一部分，但編程語言和開發(fā)工具通常提供一些機(jī)制來支持編寫和使用鉤子。

下面我們簡(jiǎn)單介紹幾種大家比較常見的利用Hook概念的技術(shù)。

Git Hook

Git Hook是一種非常強(qiáng)大的Git自定義「腳本系統(tǒng)」，它允許我們?cè)贕it版本控制過程的不同階段執(zhí)行自定義操作。這些操作可以是自動(dòng)化測(cè)試、代碼格式化、驗(yàn)證提交消息格式、預(yù)防性錯(cuò)誤檢查等等。Git hooks是一種強(qiáng)大的自定義工具，可以提高代碼質(zhì)量和協(xié)作效率。

1. 「Git Hook的種類」： Git提供了多種不同類型的Hook，每種類型對(duì)應(yīng)著Git操作的不同階段。以下是一些常見的Git掛鉤類型：

「pre-commit」：在執(zhí)行實(shí)際提交之前運(yùn)行，用于執(zhí)行「預(yù)提交檢查」。

「pre-push」：在執(zhí)行實(shí)際推送之前運(yùn)行，用于「驗(yàn)證推送到遠(yuǎn)程倉庫的內(nèi)容」。

「pre-receive」：在接收端執(zhí)行，通常用于「驗(yàn)證推送到遠(yuǎn)程倉庫的提交」。

「post-receive」：在接收端執(zhí)行，通常用于「通知或自動(dòng)化部署」。

2. 「Hook的位置」： 每個(gè)Git存儲(chǔ)庫都有一個(gè).git/hooks目錄，其中包含用于存儲(chǔ)各種Hook腳本的文件。當(dāng)我們?cè)诖鎯?chǔ)庫中運(yùn)行g(shù)it init時(shí)，Git會(huì)為我們創(chuàng)建示例Hook文件，我們可以根據(jù)需要編輯或替換它們。這些示例文件以.sample為擴(kuò)展名。
3. 「編寫Git Hook」： 要編寫Git Hook，我們只需創(chuàng)建一個(gè)可執(zhí)行的腳本文件并將其放入.git/hooks目錄中。腳本的名稱必須與hook類型相匹配（例如，pre-commit）。在腳本中，我們可以執(zhí)行任何自定義操作，例如檢查代碼、驗(yàn)證提交消息、運(yùn)行測(cè)試等。

git diff

git diff命令后通常需要跟兩個(gè)參數(shù)，參數(shù)1是要比較的舊代碼，參數(shù)2是要比較的新代碼。如果只寫一個(gè)參數(shù)，表示默認(rèn)跟 workspace 中的代碼作比較。

?

git diff 顯示的結(jié)果為「第二個(gè)參數(shù)所指的代碼在第一個(gè)參數(shù)所指代碼基礎(chǔ)上的修改」

?

• git diff:查看 workspace 與 index 的差別
• git diff --cached:查看 index 與 local repositorty 的差別
• git diff HEAD:查看 workspace 和 local repository 的差別

HEAD 指向的是 local repository 中的代碼最新提交版本

• git diff HEAD^ 是比較 workspace 與最新commit的前一次commit的差異，與git diff HEAD的是不同的
• git diff HEAD~2 是比較 workspace 與上2次commit的差異，相當(dāng)于 git diff HEAD~2 HEAD~0，注意兩個(gè)HEAD的位置，diff顯示的結(jié)果表示 參數(shù)2(HEAD~0) 相對(duì)于參數(shù)1(HEAD~2)的修改

git 別名

在Git中，別名（Git Aliases）是一種機(jī)制，允許我們?yōu)槌Ｓ玫腉it命令或命令序列創(chuàng)建簡(jiǎn)短的自定義命令。別名使我們可以用更短、更易記的名稱來執(zhí)行常用的Git操作，提高工作效率。

「1. 創(chuàng)建別名：」 我們可以使用git config命令來創(chuàng)建Git別名。

git config --global alias.<alias-name> <git-command-or-sequence>

• <alias-name>：自定義別名的名稱，我們可以選擇任何喜歡的名稱。
• <git-command-or-sequence>：要與別名關(guān)聯(lián)的Git命令或命令序列。

「2. 例子：」 以下是一些Git別名的例子：

git config --global alias.co checkout        # 創(chuàng)建 'co' 別名來代替 'checkout'
git config --global alias.br branch          # 創(chuàng)建 'br' 別名來代替 'branch'
git config --global alias.ci commit          # 創(chuàng)建 'ci' 別名來代替 'commit'
git config --global alias.st status          # 創(chuàng)建 'st' 別名來代替 'status'
git config --global alias.unstage 'reset HEAD --'  # 創(chuàng)建 'unstage' 別名來取消暫存

「3. 使用別名：」 創(chuàng)建別名后，我們可以在命令行中使用它們。例如，使用上面的例子，我們可以這樣執(zhí)行命令：

git co my-branch     # 等同于 'git checkout my-branch'
git br -a            # 等同于 'git branch -a'
git ci -m "Message"  # 等同于 'git commit -m "Message"'
git st               # 等同于 'git status'
git unstage file.txt # 等同于 'git reset HEAD -- file.txt'

從基本層面上說，Git只是一堆「通過文件名相互關(guān)聯(lián)的文本文件」。

還有一點(diǎn)需要提前聲明，如果大家也在自己的電腦中進(jìn)行實(shí)驗(yàn)，下面文章中出現(xiàn)的各種hash值，都是和內(nèi)容有關(guān)系。所以，大家要和自己的內(nèi)容對(duì)號(hào)入座，不要和本文中的hash值比較。

2. git init

為了演示方便，我們?cè)诒镜氐暮线m的文件夾中新建了一個(gè)dot_git的項(xiàng)目。

mkdir dot_git

與此同時(shí)通過git init來初始化項(xiàng)目。

圖片

現(xiàn)在讓我們來看看.git文件夾中有什么內(nèi)容。

我們使用erd來查看文件結(jié)構(gòu)。

erd -y inverted .git

文檔結(jié)構(gòu)如下

圖片

看起來它創(chuàng)建了一堆文件和文件夾。讓我們挑幾個(gè)重要的來解釋一下：

• hooks包含了在Git執(zhí)行任何操作之前/之后可以運(yùn)行的腳本。
• HEAD 指向的是 local repository 中的代碼最新提交版本

根據(jù)我們?cè)O(shè)置的“默認(rèn)”分支是什么（git config --global init.defaultBranch <分支名稱>），它將是refs/heads/master(默認(rèn))，refs/heads/main，或者我們?cè)O(shè)置的其他分支名稱。

圖片

「它指向了refs/heads文件夾」，并指向一個(gè)叫做master的文件，這個(gè)文件在我們進(jìn)行第一次提交之前是不存在的。

這個(gè)master文件「只會(huì)在我們進(jìn)行第一次提交后出現(xiàn)」。

• config是一個(gè)「文本文件」，它包含了「當(dāng)前倉庫的Git配置」。

• 如果我們查看它，我們會(huì)看到一些關(guān)于我們的倉庫的基本設(shè)置，比如是否bare、文件模式等。

• objects包含了Git對(duì)象，也就是關(guān)于倉庫中文件、提交等的「數(shù)據(jù)」。（這個(gè)狠最重要，狠重要）

• refs，存儲(chǔ)引用（指針）的地方。

• refs/heads包含分支的指針

• refs/tags包含標(biāo)簽的指針

3. 新增一個(gè)文件

現(xiàn)在，我們已經(jīng)了解了.git目錄中初始文件的情況，讓我們執(zhí)行第一個(gè)將內(nèi)容添加到.git目錄的操作。我們將創(chuàng)建一個(gè)文件并將其添加到暫存區(qū)（但還沒有提交）。

echo 'hello,789' > file
git add file

我們繼續(xù)使用erd -y inverted .git來查看文件變化。

圖片

git add file這會(huì)引起兩個(gè)主要的更改。

• 首先，它新增了索引文件（index）。Index用于存儲(chǔ)有關(guān)「當(dāng)前暫存區(qū)」的信息，用于表示名為file的文件已被添加到暫存區(qū)。
• 第二個(gè)更為重要的更改是「添加」了一個(gè)新文件夾objects/c3，其中包含一個(gè)名為dc8e6cf3e1117a8d9731ddde9916da644296aa的文件。這是Git中存儲(chǔ)對(duì)象的部分。

窺探objects中信息

我們使用file來查看一下內(nèi)容是何方神圣。

file .git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa
.git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa: zlib compressed data

結(jié)果顯示這是經(jīng)過zlib壓縮的數(shù)據(jù)。這就很讓人抓馬。「你有張良計(jì),我有過墻梯」，我們可以使用zlib庫對(duì)其解壓處理。

zlib-flate -uncompress < .git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa
blob 10hello,789

結(jié)果顯示它包含了文件名為file的文件的類型、大小和數(shù)據(jù)。

也就是說，/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa表示它是一個(gè)大小為10的blob，內(nèi)容是hello,789的數(shù)據(jù)。（只不過是被zlib處理了）

上面提到的/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa這是Git對(duì)象的一部分，用于存儲(chǔ)文件內(nèi)容。

注意，此時(shí)我們用到了zlib庫，我們可以通過brew install zlib下載該庫。(我是Mac環(huán)境，其他環(huán)境大家自行尋找解決方案)

文件名的由來

文件名來自內(nèi)容的SHA-1 hash值。

如果我們將zlib壓縮的數(shù)據(jù)通過sha1sum命令處理，我們會(huì)得到文件名。

$ zlib-flate -uncompress <.git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa | sha1sum
c3dc8e6cf3e1117a8d9731ddde9916da644296aa

Git使用內(nèi)容的SHA-1散列值，取「前兩個(gè)字符」（在這種情況下是c3），創(chuàng)建一個(gè)文件夾，然后將剩余部分用作文件名。Git從前兩個(gè)字符創(chuàng)建文件夾，以確保我們不會(huì)在單個(gè)objects文件夾下有太多文件。

在Mac環(huán)境下，我們需要通過brew install md5sha1sum

git cat-file

由于objects的內(nèi)容在Git中比較重要，Git還特意提供了一個(gè)名為git cat-file的命令，用于查看git對(duì)象的內(nèi)容。 使用git cat-file命令

• 帶有-t選項(xiàng)查看類型(type)
• 帶有-s選項(xiàng)查看大小(size)
• 帶有-p選項(xiàng)查看內(nèi)容(pretty-print)

• 這個(gè)選項(xiàng)用于顯示 Git 對(duì)象的內(nèi)容，以更易讀的方式呈現(xiàn)，通常用于查看提交、樹或標(biāo)簽對(duì)象的內(nèi)容

git cat-file -t c3dc8e6cf3e1117a8d9731ddde9916da644296aa
blob

git cat-file -s c3dc8e6cf3e1117a8d9731ddde9916da644296aa
10

git cat-file -p c3dc8e6cf3e1117a8d9731ddde9916da644296aa
hello,789

4. git commit

既然，已經(jīng)將內(nèi)容通過git add 添加到Index（暫存區(qū)），接下來我們就需要將內(nèi)容commit到local repository：(本地倉庫)

前面講過，下面的ci等同于commit。

git ci -m '首次提交'

繼續(xù)使用erd -y inverted .git 來查看目錄結(jié)構(gòu)

圖片

嚯，一下多了很多文件。讓我們來解讀一下。

首先是一個(gè)新文件COMMIT_EDITMSG，它包含了（最新的）提交消息。

如果我們運(yùn)行g(shù)it ci命令而沒有使用-m標(biāo)志，那么Git獲取提交消息的方式是打開一個(gè)文本編輯器，使用COMMIT_EDITMSG文件來讓用戶編輯提交消息。一旦用戶更新了消息并退出編輯器，Git就會(huì)使用該文件的內(nèi)容作為提交消息。

它還添加了一個(gè)全新的logs文件夾。這是Git用來「記錄倉庫中所有提交更改的一種方式」。我們將能夠「在這里看到所有refs和HEAD的提交更改」。

在refs/heads目錄，其中新增了一個(gè)名為master的文件。這是對(duì)主分支（master）的引用。

使用cat查看對(duì)于的內(nèi)容信息。

cat .git/refs/heads/master
fe010b33df5078cdbd96f2397aad60ec5f42a967

看起來它指向了其中一個(gè)新對(duì)象。我們用內(nèi)置命令cat-file查看內(nèi)容。

$ git cat-file -t fe010b33df5078cdbd96f2397aad60ec5f42a967
commit

$ git cat-file -p fe010b33df5078cdbd96f2397aad60ec5f42a967
tree 658524b859ae78d902597253a3b68b4da3b70466
author xxx <xxx@simple> 1697178492 +0800
committer xxx <xxx@xxx> 1697178492 +0800

首次提交

我們也可以使用以下命令查看該引用的類型：git cat-file -t refs/heads/master

看起來這是一種新的對(duì)象類型，似乎是一個(gè)「提交對(duì)象」（commit object）。提交對(duì)象的內(nèi)容告訴我們，它包含一個(gè)哈希為658524b859ae78d902597253a3b68b4da3b70466的「樹對(duì)象」（tree object），這看起來就像我們?cè)谔峤粫r(shí)添加的另一個(gè)對(duì)象。提交對(duì)象還包含了作者和提交者的信息。最后，它還顯示了這個(gè)提交的提交消息是什么。

我們繼續(xù)來看看樹對(duì)象包含了什么內(nèi)容。

git cat-file -t 658524b859ae78d902597253a3b68b4da3b70466
tree

git cat-file -p 658524b859ae78d902597253a3b68b4da3b70466
100644 blob c3dc8e6cf3e1117a8d9731ddde9916da644296aa    file

我們會(huì)發(fā)現(xiàn)該文件指向了在我們執(zhí)行g(shù)it add file時(shí)添加的原始對(duì)象(c3dc8e6cf3e1117a8d9731ddde9916da644296aa)。

圖片

樹對(duì)象內(nèi)部使用更多的樹對(duì)象來表示文件夾，這些樹對(duì)象與提交對(duì)象相連，用于表示目錄結(jié)構(gòu)。

5. 新增修改

讓我們對(duì)文件進(jìn)行更改并查看它是如何工作的。

echo 'git,hello,789' > file

git ci -am "修改文件內(nèi)容"

還是利用erd查看文檔目錄

圖片

• 創(chuàng)建了3個(gè)新的對(duì)象。

一個(gè)包含文件新內(nèi)容的blob對(duì)象

一個(gè)是一個(gè)樹對(duì)象

最后一個(gè)是一個(gè)提交對(duì)象

讓我們?cè)俅螐腍EAD或refs/heads/master開始跟蹤它們。

git cat-file -p refs/heads/master
tree 02185c57f2040abcaa0c67dfd7026464d916da2b
parent fe010b33df5078cdbd96f2397aad60ec5f42a967
author 789 <789@xx.net> 1697179597 +0800
committer 789 <789@xxx.net> 1697179597 +0800

修改文件內(nèi)容

git cat-file -p 02185c57f2040abcaa0c67dfd7026464d916da2b
100644 blob 1f9224976e282aa9e32398a5bca0cec08041f1dc    file

git cat-file -p 1f9224976e282aa9e32398a5bca0cec08041f1dc
git,hello,789

提交對(duì)象現(xiàn)在有一個(gè)額外的屬性，名為parent，它鏈接到「前一個(gè)提交」，因?yàn)檫@個(gè)提交是建立在前一個(gè)提交之上的。

這是Git中的提交歷史的關(guān)鍵概念，

每個(gè)提交都有一個(gè)或多個(gè)父提交，形成一個(gè)提交鏈。

6. 創(chuàng)建分支

是時(shí)候創(chuàng)建一個(gè)分支了。讓我們使用git br fix-text命令創(chuàng)建一個(gè)名為fix-text的分支。

前面講過，下面的br等同于branch。

圖片

這將在refs/heads文件夾下創(chuàng)建一個(gè)新文件，文件名為分支名稱，文件內(nèi)容為最新提交的ID。

我們首先用git log查看提交記錄

圖片

發(fā)現(xiàn)最新的提交記錄為efa223e697c6452a393963887f9926ea0662c923

cat .git/refs/heads/fix-text
efa223e697c6452a393963887f9926ea0662c923

在Git中，分支是非常輕量級(jí)的。標(biāo)簽（Tags）的行為也類似，只不過它們是創(chuàng)建在refs/tags下的。

還會(huì)在logs目錄下添加一個(gè)文件，用于存儲(chǔ)與主分支類似的提交歷史數(shù)據(jù)。這有助于跟蹤各個(gè)分支的提交歷史。Git的分支和標(biāo)簽是非常有用的版本控制工具，可以幫助我們管理項(xiàng)目的不同狀態(tài)和版本。

7. 分支切換

在Git中，檢出（checkout）操作是獲取「提交」的樹對(duì)象，并將working tree中的文件更新為與樹對(duì)象記錄的狀態(tài)相匹配。

圖片

在這種情況下，因?yàn)槲覀儚膍aster切換到fix-text，而這兩個(gè)分支「都指向相同的提交和底層樹對(duì)象」，Git在working tree中沒有任何事情要處理。

前面講過，下面的co等同于checkout。

git co fix-text

在.git目錄內(nèi)執(zhí)行co操作時(shí)，唯一的變化是.git/HEAD文件現(xiàn)在將指向fix-text。

cat .git/HEAD
ref: refs/heads/fix-text

另外，讓我進(jìn)行一次提交。

echo 'hello,git' > file

git ci -am "更換文本內(nèi)容"

這將在fix-text分支上創(chuàng)建一個(gè)新的commit，將文件file中的內(nèi)容更改為hello,git。

8. 分支合并

合并（merging）有主要三種方式。

1. 最簡(jiǎn)單和最容易的方式是「快進(jìn)合并」（fast forward merge）

• 在這種情況下，我們只需將一個(gè)分支指向另一個(gè)分支指向的commit object。
• 這實(shí)際上涉及將refs/heads/fix-text中的hash復(fù)制到refs/heads/master。

2. 第二種方式是「變基合并」（rebase merge）

• 在這種情況下，我們首先逐個(gè)將我們的更改應(yīng)用到主分支（main或master）當(dāng)前指向的每個(gè)提交，然后執(zhí)行類似于快進(jìn)合并的操作。

3. 最后一種方式是通過創(chuàng)建一個(gè)獨(dú)立的合并提交來合并兩個(gè)分支。

• 這在于它將在其提交對(duì)象中有兩個(gè)父節(jié)點(diǎn)（parent entries）。

首先，讓我們看看在合并之前圖形是什么樣子。(先將分支切換回master(git co master))

git log --graph --oneline --all

* 4359ab4 (fix-text) 更換文本內(nèi)容
* efa223e (HEAD -> master) 修改文件內(nèi)容
* fe010b3 首次提交

執(zhí)行合并操作

git merge fix-text
更新 efa223e..4359ab4
Fast-forward
 file | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

上面的操作，將一個(gè)master分支的引用（指向的哈希值）更新為fix-text分支的引用指向的哈希值。

git log --graph --oneline --all

* 4359ab4 (HEAD -> master, fix-text) 更換文本內(nèi)容
* efa223e 修改文件內(nèi)容
* fe010b3 首次提交

9. 遠(yuǎn)程提交

為了演示這一點(diǎn)，首先讓我創(chuàng)建另一個(gè)Git倉庫，它可以作為這個(gè)倉庫的遠(yuǎn)程倉庫。

新建一個(gè)「裸」倉庫

$ mkdir fake_git_remote
$ cd fake_git_remote && git init --bare

切換到我們dot_git項(xiàng)目中，為倉庫設(shè)置remote

git remote add origin ../fake_git_remote

順便說一下，添加一個(gè)新的遠(yuǎn)程倉庫是一項(xiàng)配置更改，我們可以在.git/config文件中查看這個(gè)更改。我會(huì)讓我們自己去查看這個(gè)更改是什么。

圖片

現(xiàn)在讓我們進(jìn)行推送操作。

git push origin master

讓我們看看我們的本地倉庫中發(fā)生了什么變化。

圖片

它添加了一個(gè)新的refs/remotes，用于存儲(chǔ)有關(guān)不同遠(yuǎn)程倉庫中的所有可用內(nèi)容的信息。

但是發(fā)送到另一個(gè)Git倉庫的是什么呢？實(shí)際上，

發(fā)送的內(nèi)容就是.git/objects目錄中的所有對(duì)象，以及我們顯式推送的refs下的所有分支和標(biāo)簽。

這就是另一個(gè)Git倉庫需要獲取我們的完整Git歷史記錄所需的一切內(nèi)容。

圖片