日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

前言

作為一個新時代的開發者，想必大家在工作中，有一樣東西是和大家「形影不離」的。那就是git。(當然，這里也有個例，如果大家項目還停留在svn階段，就算我剛才的話唐突了)。

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

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

所有軟件的底層實現都是「操作和管理數據」。

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

這里簡單舉一個例子，日歷大家都見過哇。

如果，給我們一個需求，要讓我們實現一個飛書日歷或者google 日歷的開發任務，我們是不是一時感覺到無法下手。

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

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

圖片

而下面的events就是我們在日歷上顯示的日程信息。

圖片

好了，天不早了，干點正事哇。

我們能所學到的知識點

1. 前置知識點
2. git init
3. 新增一個文件
4. git commit
5. 新增修改
6. 創建分支
7. 分支切換
8. 分支合并
9. 遠程提交

1. 前置知識點

「前置知識點」，只是做一個概念的介紹，不會做深度解釋。因為，這些概念在下面文章中會有出現，為了讓行文更加的順暢，所以將本該在文內的概念解釋放到前面來。「如果大家對這些概念熟悉，可以直接忽略」同時，由于閱讀我文章的群體有很多，所以有些知識點可能「我視之若珍寶，爾視只如草芥，棄之如敝履」。以下知識點，請「酌情使用」。

什么是git

Git是一種用于源代碼管理的工具。它是一個免費且開源的版本控制系統，用于高效地處理從小型到非常大型的項目。Git用于跟蹤源代碼的更改，使多個開發人員能夠共同在非線性開發中合作。Git是由Linus Torvalds于2005年為linux內核的開發而創建的。

集中式管理

在使用Git之前在維護代碼之前，團隊合作的模式如下：

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

圖片

它的典型代表為SVN

分布式管理

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

圖片

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

git基礎概念

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

• 它還有一個家喻戶曉的名字 -「暫存區」

• local repository：是「本地倉庫」，當我們使用git commit命令提交最新代碼時，代碼才真正進入git倉庫。

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

• remote repository：是「遠程倉庫」，當我們使用git push命令時就會將本地倉庫的代碼上傳至遠程倉庫，完成整個代碼的上傳工作

圖片

git init --bare VS git init

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

下面是它們之間的主要區別：

1. 「倉庫類型」:

• git init: 這個命令用于創建一個「標準的Git工作目錄倉庫」。它會在當前目錄下創建一個.git子目錄，其中「包含Git的版本控制文件和歷史記錄」（這是我們這篇文章的重點）。這種類型的倉庫通常用于開發和維護代碼。
• git init --bare: 這個命令用于創建一個"裸"（bare）倉庫，它不包含工作目錄。這意味著它只包含Git版本控制的文件和歷史記錄，「沒有實際的項目文件」。"裸"倉庫通常用作「中央版本庫」，用于協作和共享代碼。

2. 「默認分支」:

• git init 默認創建一個帶有master分支的工作目錄倉庫。

• git init --bare 默認不創建分支，因為裸倉庫不包含工作目錄。我們需要手動創建和設置分支。

   

一般情況下，如果我們需要創建一個新的Git倉庫用于開發和維護代碼，我們應該使用 git init。如果我們需要創建一個中央版本庫用于團隊協作和共享代碼，我們可以考慮使用 git init --bare。

Hook

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

下面我們簡單介紹幾種大家比較常見的利用Hook概念的技術。

名稱	描述	示例語法
Git Hooks	Git 允許在代碼倉庫的特定事件上運行自定義腳本。事件包括提交、推送、合并等。	使用 Bash 腳本編寫，如 pre-commit、post-commit 等。
JAVAScript Hooks	JavaScript 用于前端和后端開發，事件處理程序在特定事件發生時執行自定義 JavaScript 代碼。	前端中，事件處理程序如事件監聽器。后端中，使用 EventEmitter 模塊。
React Lifecycle Hooks	React 用于構建用戶界面，包括生命周期方法，允許在組件的不同生命周期階段運行自定義代碼。	生命周期方法如 componentDidMount 和 componentWillUnmount。 當然，還有甚囂塵上的針對函數組件的React Hook
Github Webhooks	GitHub 提供 Webhooks，是 HTTP 回調，用于在存儲庫的特定事件上觸發自定義操作。	開發者編寫 Webhook 處理程序響應事件，配置 Webhook URL。
Jenkins Pipeline Hooks	Jenkins 是一個持續集成工具，允許創建自定義流水線腳本。使用鉤子定義流水線的階段和操作。	鉤子嵌入到 Jenkinsfile 中以定義流水線。

Git Hook

Git Hook是一種非常強大的Git自定義「腳本系統」，它允許我們在Git版本控制過程的不同階段執行自定義操作。這些操作可以是自動化測試、代碼格式化、驗證提交消息格式、預防性錯誤檢查等等。Git hooks是一種強大的自定義工具，可以提高代碼質量和協作效率。

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

「pre-commit」：在執行實際提交之前運行，用于執行「預提交檢查」。

「pre-push」：在執行實際推送之前運行，用于「驗證推送到遠程倉庫的內容」。

「pre-receive」：在接收端執行，通常用于「驗證推送到遠程倉庫的提交」。

「post-receive」：在接收端執行，通常用于「通知或自動化部署」。

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

---

git diff

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

?

git diff 顯示的結果為「第二個參數所指的代碼在第一個參數所指代碼基礎上的修改」

?

• 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顯示的結果表示 參數2(HEAD~0) 相對于參數1(HEAD~2)的修改

git 別名

在Git中，別名（Git Aliases）是一種機制，允許我們為常用的Git命令或命令序列創建簡短的自定義命令。別名使我們可以用更短、更易記的名稱來執行常用的Git操作，提高工作效率。

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

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

<alias-name>：自定義別名的名稱，我們可以選擇任何喜歡的名稱。

• <git-command-or-sequence>：要與別名關聯的Git命令或命令序列。

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

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

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

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只是一堆「通過文件名相互關聯的文本文件」。

還有一點需要提前聲明，如果大家也在自己的電腦中進行實驗，下面文章中出現的各種hash值，都是和內容有關系。所以，大家要和自己的內容對號入座，不要和本文中的hash值比較。

2. git init

為了演示方便，我們在本地的合適的文件夾中新建了一個dot_git的項目。

mkdir dot_git

與此同時通過git init來初始化項目。

圖片

現在讓我們來看看.git文件夾中有什么內容。

我們使用erd來查看文件結構。

erd -y inverted .git

文檔結構如下

圖片

看起來它創建了一堆文件和文件夾。讓我們挑幾個重要的來解釋一下：

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

根據我們設置的“默認”分支是什么（git config --global init.defaultBranch <分支名稱>），它將是refs/heads/master(默認)，refs/heads/mAIn，或者我們設置的其他分支名稱。

 

圖片

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

這個master文件「只會在我們進行第一次提交后出現」。

• config是一個「文本文件」，它包含了「當前倉庫的Git配置」。

• 如果我們查看它，我們會看到一些關于我們的倉庫的基本設置，比如是否bare、文件模式等。

• objects包含了Git對象，也就是關于倉庫中文件、提交等的「數據」。（這個狠最重要，狠重要）

• refs，存儲引用（指針）的地方。

• refs/heads包含分支的指針

• refs/tags包含標簽的指針

3. 新增一個文件

現在，我們已經了解了.git目錄中初始文件的情況，讓我們執行第一個將內容添加到.git目錄的操作。我們將創建一個文件并將其添加到暫存區（但還沒有提交）。

echo 'hello,789' > file
git add file

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

圖片

git add file這會引起兩個主要的更改。

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

窺探objects中信息

我們使用file來查看一下內容是何方神圣。

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

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

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

結果顯示它包含了文件名為file的文件的類型、大小和數據。

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

上面提到的/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa這是Git對象的一部分，用于存儲文件內容。

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

文件名的由來

文件名來自內容的SHA-1 hash值。

如果我們將zlib壓縮的數據通過sha1sum命令處理，我們會得到文件名。

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

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

在Mac環境下，我們需要通過brew install md5sha1sum

git cat-file

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

• 帶有-t選項查看類型(type)
• 帶有-s選項查看大小(size)
• 帶有-p選項查看內容(pretty-print)

• 這個選項用于顯示 Git 對象的內容，以更易讀的方式呈現，通常用于查看提交、樹或標簽對象的內容

git cat-file -t c3dc8e6cf3e1117a8d9731ddde9916da644296aa
blob

git cat-file -s c3dc8e6cf3e1117a8d9731ddde9916da644296aa
10

git cat-file -p c3dc8e6cf3e1117a8d9731ddde9916da644296aa
hello,789

4. git commit

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

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

git ci -m '首次提交'

繼續使用erd -y inverted .git 來查看目錄結構

圖片

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

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

如果我們運行git ci命令而沒有使用-m標志，那么Git獲取提交消息的方式是打開一個文本編輯器，使用COMMIT_EDITMSG文件來讓用戶編輯提交消息。一旦用戶更新了消息并退出編輯器，Git就會使用該文件的內容作為提交消息。

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

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

使用cat查看對于的內容信息。

cat .git/refs/heads/master
fe010b33df5078cdbd96f2397aad60ec5f42a967

看起來它指向了其中一個新對象。我們用內置命令cat-file查看內容。

$ 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）。提交對象的內容告訴我們，它包含一個哈希為658524b859ae78d902597253a3b68b4da3b70466的「樹對象」（tree object），這看起來就像我們在提交時添加的另一個對象。提交對象還包含了作者和提交者的信息。最后，它還顯示了這個提交的提交消息是什么。

我們繼續來看看樹對象包含了什么內容。

git cat-file -t 658524b859ae78d902597253a3b68b4da3b70466
tree

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

我們會發現該文件指向了在我們執行git add file時添加的原始對象(c3dc8e6cf3e1117a8d9731ddde9916da644296aa)。

圖片

樹對象內部使用更多的樹對象來表示文件夾，這些樹對象與提交對象相連，用于表示目錄結構。

5. 新增修改

讓我們對文件進行更改并查看它是如何工作的。

echo 'git,hello,789' > file

git ci -am "修改文件內容"

還是利用erd查看文檔目錄

圖片

• 創建了3個新的對象。

一個包含文件新內容的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

修改文件內容

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

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

提交對象現在有一個額外的屬性，名為parent，它鏈接到「前一個提交」，因為這個提交是建立在前一個提交之上的。

這是Git中的提交歷史的關鍵概念，

每個提交都有一個或多個父提交，形成一個提交鏈。

6. 創建分支

是時候創建一個分支了。讓我們使用git br fix-text命令創建一個名為fix-text的分支。

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

圖片

這將在refs/heads文件夾下創建一個新文件，文件名為分支名稱，文件內容為最新提交的ID。

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

圖片

發現最新的提交記錄為efa223e697c6452a393963887f9926ea0662c923

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

在Git中，分支是非常輕量級的。標簽（Tags）的行為也類似，只不過它們是創建在refs/tags下的。

還會在logs目錄下添加一個文件，用于存儲與主分支類似的提交歷史數據。這有助于跟蹤各個分支的提交歷史。Git的分支和標簽是非常有用的版本控制工具，可以幫助我們管理項目的不同狀態和版本。

7. 分支切換

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

圖片

在這種情況下，因為我們從master切換到fix-text，而這兩個分支「都指向相同的提交和底層樹對象」，Git在working tree中沒有任何事情要處理。

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

git co fix-text

在.git目錄內執行co操作時，唯一的變化是.git/HEAD文件現在將指向fix-text。

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

另外，讓我進行一次提交。

echo 'hello,git' > file

git ci -am "更換文本內容"

這將在fix-text分支上創建一個新的commit，將文件file中的內容更改為hello,git。

8. 分支合并

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

1. 最簡單和最容易的方式是「快進合并」（fast forward merge）

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

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

• 在這種情況下，我們首先逐個將我們的更改應用到主分支（main或master）當前指向的每個提交，然后執行類似于快進合并的操作。

3. 最后一種方式是通過創建一個獨立的合并提交來合并兩個分支。

• 這在于它將在其提交對象中有兩個父節點（parent entries）。

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

git log --graph --oneline --all

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

執行合并操作

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) 更換文本內容
* efa223e 修改文件內容
* fe010b3 首次提交

9. 遠程提交

為了演示這一點，首先讓我創建另一個Git倉庫，它可以作為這個倉庫的遠程倉庫。

新建一個「裸」倉庫

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

切換到我們dot_git項目中，為倉庫設置remote

git remote add origin ../fake_git_remote

順便說一下，添加一個新的遠程倉庫是一項配置更改，我們可以在.git/config文件中查看這個更改。我會讓我們自己去查看這個更改是什么。

圖片

現在讓我們進行推送操作。

git push origin master

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

圖片

它添加了一個新的refs/remotes，用于存儲有關不同遠程倉庫中的所有可用內容的信息。

但是發送到另一個Git倉庫的是什么呢？實際上，

發送的內容就是.git/objects目錄中的所有對象，以及我們顯式推送的refs下的所有分支和標簽。

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

 圖片