您有一篇Git 原理,請注意查收
前言
作為一個新時代的開發(fā)者,想必大家在工作中,有一樣?xùn)|西是和大家「形影不離」的。那就是git。(當然,這里也有個例,如果大家項目還停留在svn階段,就算我剛才的話唐突了)。
無論大家平時是喜歡在命令行中手搓git命令,還是利用git可視化工具(SourceTree)進行代碼管理。終究都逃不過,add/commit/merge/push等命令的支配。所以,今天我們來聊聊,在進行這些命令的時候,在最底層到底發(fā)生了啥。
還有一點,也算是一個認知提升吧。需要和大家嘮叨一下,以后遇到比較棘手的問題,可以往這方面來靠攏
所有軟件的底層實現(xiàn)都是「操作和管理數(shù)據(jù)」。
無論是我們平時用到的桌面程序,亦或是在命令行中進行敲敲打打處理一些特定的操作,還有就是我們熟悉的編程開發(fā)中,無論是前端的開發(fā)過程中,使用原生也好,各種框架也罷,最后的根結(jié)都是數(shù)據(jù)的羅列和排布;還是后端就更明顯了,有SQL的操作,那就更是再「玩弄」數(shù)據(jù)。 之所以我們看到的現(xiàn)象有些不同,無非就是數(shù)據(jù)的表現(xiàn)形式和處理方式的不同??梢哉f,在編程界,--「萬物皆數(shù)據(jù)」。
這里簡單舉一個例子,日歷大家都見過哇。
如果,給我們一個需求,要讓我們實現(xiàn)一個飛書日歷或者google 日歷的開發(fā)任務(wù),我們是不是一時感覺到無法下手。
那我們往「萬物皆數(shù)據(jù)」這個定論上靠,那是不是每一個「日程」(無論是簡單日程還是重復(fù)日程),它們本質(zhì)上就是在每個小格子上展示。無非就是有的日程在單個格子上,有的日程是跨格子。 而針對這種情況,是不是就是在當前視圖中,我們需要維護一個數(shù)組,而這個數(shù)組中的項就是每個格子的示例。(針對月視圖/周視圖/日視圖的數(shù)據(jù),其實都是一套,只不過在框架內(nèi)部為我們提供了各自的展示邏輯)
這是一個開源的日歷庫(FullCalendar)。
圖片
而下面的events就是我們在日歷上顯示的日程信息。
圖片
好了,天不早了,干點正事哇。
我們能所學(xué)到的知識點
- 前置知識點
- git init
- 新增一個文件
- git commit
- 新增修改
- 創(chuàng)建分支
- 分支切換
- 分支合并
- 遠程提交
1. 前置知識點
「前置知識點」,只是做一個概念的介紹,不會做深度解釋。因為,這些概念在下面文章中會有出現(xiàn),為了讓行文更加的順暢,所以將本該在文內(nèi)的概念解釋放到前面來?!溉绻蠹覍@些概念熟悉,可以直接忽略」同時,由于閱讀我文章的群體有很多,所以有些知識點可能「我視之若珍寶,爾視只如草芥,棄之如敝履」。以下知識點,請「酌情使用」。
什么是git
Git是一種用于源代碼管理的工具。它是一個免費且開源的版本控制系統(tǒng),用于高效地處理從小型到非常大型的項目。Git用于跟蹤源代碼的更改,使多個開發(fā)人員能夠共同在非線性開發(fā)中合作。Git是由Linus Torvalds于2005年為Linux內(nèi)核的開發(fā)而創(chuàng)建的。
集中式管理
在使用Git之前在維護代碼之前,團隊合作的模式如下:
- 開發(fā)人員過去會將他們的代碼提交到「中央服務(wù)器」,而沒有自己的副本。
- 對源代碼所做的任何更改對其他開發(fā)人員來說都是「未知的」。
- 沒有任何開發(fā)人員之間的溝通。
圖片
它的典型代表為SVN
分布式管理
- 每個開發(fā)人員都在其本地系統(tǒng)上擁有「完整的代碼副本」。
- 對源代碼所做的任何更改都可以「被其他人跟蹤」。
- 開發(fā)人員之間有定期的溝通。
圖片
毋庸置疑,git是這方面的王者。
git基礎(chǔ)概念
- workspace:是本地項目的工作目錄,屬于「本地代碼發(fā)生更新但尚未執(zhí)行 git add 命令時的狀態(tài)」,working tree的狀態(tài)也隨之更新
- index:是索引文件,它是連接working tree和commit的橋梁,每當我們使用git add命令來登記后,index file的內(nèi)容就會改變,此時index file就和working tree同步了。
- 它還有一個家喻戶曉的名字 -「暫存區(qū)」
- local repository:是「本地倉庫」,當我們使用git commit命令提交最新代碼時,代碼才真正進入git倉庫。
git commit -m “xxx” 就是「將 index 里的內(nèi)容提交到本地倉庫中」
remote repository:是「遠程倉庫」,當我們使用git push命令時就會將本地倉庫的代碼上傳至遠程倉庫,完成整個代碼的上傳工作
圖片
git init --bare VS git init
git init --bare 和 git init 是兩種不同的Git初始化命令,它們用于創(chuàng)建不同類型的Git倉庫。
下面是它們之間的主要區(qū)別:
- 「倉庫類型」:
- git init: 這個命令用于創(chuàng)建一個「標準的Git工作目錄倉庫」。它會在當前目錄下創(chuàng)建一個.git子目錄,其中「包含Git的版本控制文件和歷史記錄」(這是我們這篇文章的重點)。這種類型的倉庫通常用于開發(fā)和維護代碼。
- git init --bare: 這個命令用于創(chuàng)建一個"裸"(bare)倉庫,它不包含工作目錄。這意味著它只包含Git版本控制的文件和歷史記錄,「沒有實際的項目文件」。"裸"倉庫通常用作「中央版本庫」,用于協(xié)作和共享代碼。
- 「默認分支」:
git init 默認創(chuàng)建一個帶有master分支的工作目錄倉庫。
git init --bare 默認不創(chuàng)建分支,因為裸倉庫不包含工作目錄。我們需要手動創(chuàng)建和設(shè)置分支。
一般情況下,如果我們需要創(chuàng)建一個新的Git倉庫用于開發(fā)和維護代碼,我們應(yīng)該使用 git init。如果我們需要創(chuàng)建一個中央版本庫用于團隊協(xié)作和共享代碼,我們可以考慮使用 git init --bare。
Hook
鉤子(Hooks)是一種通用概念,通常用于「在特定事件發(fā)生時觸發(fā)自定義代碼」。雖然不是編程語言本身的一部分,但編程語言和開發(fā)工具通常提供一些機制來支持編寫和使用鉤子。
下面我們簡單介紹幾種大家比較常見的利用Hook概念的技術(shù)。
名稱 | 描述 | 示例語法 |
Git Hooks | Git 允許在代碼倉庫的特定事件上運行自定義腳本。事件包括提交、推送、合并等。 | 使用 Bash 腳本編寫,如 |
JavaScript Hooks | JavaScript 用于前端和后端開發(fā),事件處理程序在特定事件發(fā)生時執(zhí)行自定義 JavaScript 代碼。 | 前端中,事件處理程序如事件監(jiān)聽器。后端中,使用 EventEmitter 模塊。 |
React Lifecycle Hooks | React 用于構(gòu)建用戶界面,包括生命周期方法,允許在組件的不同生命周期階段運行自定義代碼。 | 生命周期方法如 當然,還有甚囂塵上的針對函數(shù)組件的 |
GitHub Webhooks | GitHub 提供 Webhooks,是 HTTP 回調(diào),用于在存儲庫的特定事件上觸發(fā)自定義操作。 | 開發(fā)者編寫 Webhook 處理程序響應(yīng)事件,配置 Webhook URL。 |
Jenkins Pipeline Hooks | Jenkins 是一個持續(xù)集成工具,允許創(chuàng)建自定義流水線腳本。使用鉤子定義流水線的階段和操作。 | 鉤子嵌入到 Jenkinsfile 中以定義流水線。 |
Git Hook
Git Hook是一種非常強大的Git自定義「腳本系統(tǒng)」,它允許我們在Git版本控制過程的不同階段執(zhí)行自定義操作。這些操作可以是自動化測試、代碼格式化、驗證提交消息格式、預(yù)防性錯誤檢查等等。Git hooks是一種強大的自定義工具,可以提高代碼質(zhì)量和協(xié)作效率。
- 「Git Hook的種類」: Git提供了多種不同類型的Hook,每種類型對應(yīng)著Git操作的不同階段。以下是一些常見的Git掛鉤類型:
「pre-commit」:在執(zhí)行實際提交之前運行,用于執(zhí)行「預(yù)提交檢查」。
「pre-push」:在執(zhí)行實際推送之前運行,用于「驗證推送到遠程倉庫的內(nèi)容」。
「pre-receive」:在接收端執(zhí)行,通常用于「驗證推送到遠程倉庫的提交」。
「post-receive」:在接收端執(zhí)行,通常用于「通知或自動化部署」。
- 「Hook的位置」: 每個Git存儲庫都有一個.git/hooks目錄,其中包含用于存儲各種Hook腳本的文件。當我們在存儲庫中運行g(shù)it init時,Git會為我們創(chuàng)建示例Hook文件,我們可以根據(jù)需要編輯或替換它們。這些示例文件以.sample為擴展名。
- 「編寫Git Hook」: 要編寫Git Hook,我們只需創(chuàng)建一個可執(zhí)行的腳本文件并將其放入.git/hooks目錄中。腳本的名稱必須與hook類型相匹配(例如,pre-commit)。在腳本中,我們可以執(zhí)行任何自定義操作,例如檢查代碼、驗證提交消息、運行測試等。
git diff
git diff命令后通常需要跟兩個參數(shù),參數(shù)1是要比較的舊代碼,參數(shù)2是要比較的新代碼。如果只寫一個參數(shù),表示默認跟 workspace 中的代碼作比較。
?
git diff 顯示的結(jié)果為「第二個參數(shù)所指的代碼在第一個參數(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的差異,相當于 git diff HEAD~2 HEAD~0,注意兩個HEAD的位置,diff顯示的結(jié)果表示 參數(shù)2(HEAD~0) 相對于參數(shù)1(HEAD~2)的修改
git 別名
在Git中,別名(Git Aliases)是一種機制,允許我們?yōu)槌S玫腉it命令或命令序列創(chuàng)建簡短的自定義命令。別名使我們可以用更短、更易記的名稱來執(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)的文本文件」。
還有一點需要提前聲明,如果大家也在自己的電腦中進行實驗,下面文章中出現(xiàn)的各種hash值,都是和內(nèi)容有關(guān)系。所以,大家要和自己的內(nèi)容對號入座,不要和本文中的hash值比較。
2. git init
為了演示方便,我們在本地的合適的文件夾中新建了一個dot_git的項目。
mkdir dot_git與此同時通過git init來初始化項目。
圖片
現(xiàn)在讓我們來看看.git文件夾中有什么內(nèi)容。
我們使用erd來查看文件結(jié)構(gòu)。
erd -y inverted .git文檔結(jié)構(gòu)如下
圖片
看起來它創(chuàng)建了一堆文件和文件夾。讓我們挑幾個重要的來解釋一下:
- hooks包含了在Git執(zhí)行任何操作之前/之后可以運行的腳本。
- HEAD 指向的是 local repository 中的代碼最新提交版本
根據(jù)我們設(shè)置的“默認”分支是什么(git config --global init.defaultBranch <分支名稱>),它將是refs/heads/master(默認),refs/heads/main,或者我們設(shè)置的其他分支名稱。
圖片
「它指向了refs/heads文件夾」,并指向一個叫做master的文件,這個文件在我們進行第一次提交之前是不存在的。
這個master文件「只會在我們進行第一次提交后出現(xiàn)」。
- config是一個「文本文件」,它包含了「當前倉庫的Git配置」。
如果我們查看它,我們會看到一些關(guān)于我們的倉庫的基本設(shè)置,比如是否bare、文件模式等。

objects包含了Git對象,也就是關(guān)于倉庫中文件、提交等的「數(shù)據(jù)」。(這個狠最重要,狠重要)
refs,存儲引用(指針)的地方。
refs/heads包含分支的指針
refs/tags包含標簽的指針
3. 新增一個文件
現(xiàn)在,我們已經(jīng)了解了.git目錄中初始文件的情況,讓我們執(zhí)行第一個將內(nèi)容添加到.git目錄的操作。我們將創(chuàng)建一個文件并將其添加到暫存區(qū)(但還沒有提交)。
echo 'hello,789' > file
git add file我們繼續(xù)使用erd -y inverted .git來查看文件變化。
圖片
git add file這會引起兩個主要的更改。
- 首先,它新增了索引文件(index)。Index用于存儲有關(guān)「當前暫存區(qū)」的信息,用于表示名為file的文件已被添加到暫存區(qū)。
- 第二個更為重要的更改是「添加」了一個新文件夾objects/c3,其中包含一個名為dc8e6cf3e1117a8d9731ddde9916da644296aa的文件。這是Git中存儲對象的部分。
窺探objects中信息
我們使用file來查看一下內(nèi)容是何方神圣。
file .git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa
.git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa: zlib compressed data結(jié)果顯示這是經(jīng)過zlib壓縮的數(shù)據(jù)。這就很讓人抓馬?!改阌袕埩加?我有過墻梯」,我們可以使用zlib庫對其解壓處理。
zlib-flate -uncompress < .git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa
blob 10hello,789結(jié)果顯示它包含了文件名為file的文件的類型、大小和數(shù)據(jù)。
也就是說,/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa表示它是一個大小為10的blob,內(nèi)容是hello,789的數(shù)據(jù)。(只不過是被zlib處理了)
上面提到的/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa這是Git對象的一部分,用于存儲文件內(nèi)容。
注意,此時我們用到了zlib庫,我們可以通過brew install zlib下載該庫。(我是Mac環(huán)境,其他環(huán)境大家自行尋找解決方案)
文件名的由來
文件名來自內(nèi)容的SHA-1 hash值。
如果我們將zlib壓縮的數(shù)據(jù)通過sha1sum命令處理,我們會得到文件名。
$ zlib-flate -uncompress <.git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa | sha1sum
c3dc8e6cf3e1117a8d9731ddde9916da644296aaGit使用內(nèi)容的SHA-1散列值,取「前兩個字符」(在這種情況下是c3),創(chuàng)建一個文件夾,然后將剩余部分用作文件名。Git從前兩個字符創(chuàng)建文件夾,以確保我們不會在單個objects文件夾下有太多文件。
在Mac環(huán)境下,我們需要通過brew install md5sha1sum
git cat-file
由于objects的內(nèi)容在Git中比較重要,Git還特意提供了一個名為git cat-file的命令,用于查看git對象的內(nèi)容。 使用git cat-file命令
- 帶有-t選項查看類型(type)
- 帶有-s選項查看大小(size)
- 帶有-p選項查看內(nèi)容(pretty-print)
- 這個選項用于顯示 Git 對象的內(nèi)容,以更易讀的方式呈現(xiàn),通常用于查看提交、樹或標簽對象的內(nèi)容
git cat-file -t c3dc8e6cf3e1117a8d9731ddde9916da644296aa
blob
git cat-file -s c3dc8e6cf3e1117a8d9731ddde9916da644296aa
10
git cat-file -p c3dc8e6cf3e1117a8d9731ddde9916da644296aa
hello,7894. 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)
圖片
嚯,一下多了很多文件。讓我們來解讀一下。
首先是一個新文件COMMIT_EDITMSG,它包含了(最新的)提交消息。
如果我們運行g(shù)it ci命令而沒有使用-m標志,那么Git獲取提交消息的方式是打開一個文本編輯器,使用COMMIT_EDITMSG文件來讓用戶編輯提交消息。一旦用戶更新了消息并退出編輯器,Git就會使用該文件的內(nèi)容作為提交消息。
它還添加了一個全新的logs文件夾。這是Git用來「記錄倉庫中所有提交更改的一種方式」。我們將能夠「在這里看到所有refs和HEAD的提交更改」。
在refs/heads目錄,其中新增了一個名為master的文件。這是對主分支(master)的引用。
使用cat查看對于的內(nèi)容信息。
cat .git/refs/heads/master
fe010b33df5078cdbd96f2397aad60ec5f42a967看起來它指向了其中一個新對象。我們用內(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
看起來這是一種新的對象類型,似乎是一個「提交對象」(commit object)。提交對象的內(nèi)容告訴我們,它包含一個哈希為658524b859ae78d902597253a3b68b4da3b70466的「樹對象」(tree object),這看起來就像我們在提交時添加的另一個對象。提交對象還包含了作者和提交者的信息。最后,它還顯示了這個提交的提交消息是什么。
我們繼續(xù)來看看樹對象包含了什么內(nèi)容。
git cat-file -t 658524b859ae78d902597253a3b68b4da3b70466
tree
git cat-file -p 658524b859ae78d902597253a3b68b4da3b70466
100644 blob c3dc8e6cf3e1117a8d9731ddde9916da644296aa file我們會發(fā)現(xiàn)該文件指向了在我們執(zhí)行g(shù)it add file時添加的原始對象(c3dc8e6cf3e1117a8d9731ddde9916da644296aa)。
圖片
樹對象內(nèi)部使用更多的樹對象來表示文件夾,這些樹對象與提交對象相連,用于表示目錄結(jié)構(gòu)。
5. 新增修改
讓我們對文件進行更改并查看它是如何工作的。
echo 'git,hello,789' > file
git ci -am "修改文件內(nèi)容"還是利用erd查看文檔目錄
圖片
- 創(chuàng)建了3個新的對象。
一個包含文件新內(nèi)容的blob對象
一個是一個樹對象
最后一個是一個提交對象
讓我們再次從HEAD或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提交對象現(xiàn)在有一個額外的屬性,名為parent,它鏈接到「前一個提交」,因為這個提交是建立在前一個提交之上的。
這是Git中的提交歷史的關(guān)鍵概念,
每個提交都有一個或多個父提交,形成一個提交鏈。
6. 創(chuàng)建分支
是時候創(chuàng)建一個分支了。讓我們使用git br fix-text命令創(chuàng)建一個名為fix-text的分支。
前面講過,下面的br等同于branch。
圖片
這將在refs/heads文件夾下創(chuàng)建一個新文件,文件名為分支名稱,文件內(nèi)容為最新提交的ID。
我們首先用git log查看提交記錄
圖片
發(fā)現(xiàn)最新的提交記錄為efa223e697c6452a393963887f9926ea0662c923
cat .git/refs/heads/fix-text
efa223e697c6452a393963887f9926ea0662c923在Git中,分支是非常輕量級的。標簽(Tags)的行為也類似,只不過它們是創(chuàng)建在refs/tags下的。
還會在logs目錄下添加一個文件,用于存儲與主分支類似的提交歷史數(shù)據(jù)。這有助于跟蹤各個分支的提交歷史。Git的分支和標簽是非常有用的版本控制工具,可以幫助我們管理項目的不同狀態(tài)和版本。
7. 分支切換
在Git中,檢出(checkout)操作是獲取「提交」的樹對象,并將working tree中的文件更新為與樹對象記錄的狀態(tài)相匹配。
圖片
在這種情況下,因為我們從master切換到fix-text,而這兩個分支「都指向相同的提交和底層樹對象」,Git在working tree中沒有任何事情要處理。
前面講過,下面的co等同于checkout。
git co fix-text在.git目錄內(nèi)執(zhí)行co操作時,唯一的變化是.git/HEAD文件現(xiàn)在將指向fix-text。
cat .git/HEAD
ref: refs/heads/fix-text另外,讓我進行一次提交。
echo 'hello,git' > file
git ci -am "更換文本內(nèi)容"這將在fix-text分支上創(chuàng)建一個新的commit,將文件file中的內(nèi)容更改為hello,git。
8. 分支合并
合并(merging)有主要三種方式。
- 最簡單和最容易的方式是「快進合并」(fast forward merge)
- 在這種情況下,我們只需將一個分支指向另一個分支指向的commit object。
- 這實際上涉及將refs/heads/fix-text中的hash復(fù)制到refs/heads/master。
- 第二種方式是「變基合并」(rebase merge)
在這種情況下,我們首先逐個將我們的更改應(yīng)用到主分支(main或master)當前指向的每個提交,然后執(zhí)行類似于快進合并的操作。
最后一種方式是通過創(chuàng)建一個獨立的合并提交來合并兩個分支。
這在于它將在其提交對象中有兩個父節(jié)點(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(-)上面的操作,將一個master分支的引用(指向的哈希值)更新為fix-text分支的引用指向的哈希值。
git log --graph --oneline --all
* 4359ab4 (HEAD -> master, fix-text) 更換文本內(nèi)容
* efa223e 修改文件內(nèi)容
* fe010b3 首次提交9. 遠程提交
為了演示這一點,首先讓我創(chuàng)建另一個Git倉庫,它可以作為這個倉庫的遠程倉庫。
新建一個「裸」倉庫
$ mkdir fake_git_remote
$ cd fake_git_remote && git init --bare切換到我們dot_git項目中,為倉庫設(shè)置remote
git remote add origin ../fake_git_remote順便說一下,添加一個新的遠程倉庫是一項配置更改,我們可以在.git/config文件中查看這個更改。我會讓我們自己去查看這個更改是什么。
圖片
現(xiàn)在讓我們進行推送操作。
git push origin master讓我們看看我們的本地倉庫中發(fā)生了什么變化。
圖片
它添加了一個新的refs/remotes,用于存儲有關(guān)不同遠程倉庫中的所有可用內(nèi)容的信息。
但是發(fā)送到另一個Git倉庫的是什么呢?實際上,
發(fā)送的內(nèi)容就是.git/objects目錄中的所有對象,以及我們顯式推送的refs下的所有分支和標簽。
這就是另一個Git倉庫需要獲取我們的完整Git歷史記錄所需的一切內(nèi)容。
圖片



























