2023年Q2用戶偏好榜：12+256G版本成新主流
3月份的性能榜、性價比榜和好評榜之后，就要輪到2023年的第二季度偏好榜了，上半年的新機潮已經過去，最明顯的肯定就是大內存和存儲的機型了，另外部分中端機也取消了屏幕塑料支架
作為一個新時代的開發者，想必大家在工作中，有一樣東西是和大家「形影不離」的。那就是git。(當然，這里也有個例，如果大家項目還停留在svn階段，就算我剛才的話唐突了)。
無論大家平時是喜歡在命令行中手搓git命令，還是利用git可視化工具(SourceTree)進行代碼管理。終究都逃不過，add/commit/merge/push等命令的支配。所以，今天我們來聊聊，在進行這些命令的時候，在最底層到底發生了啥。
還有一點，也算是一個認知提升吧。需要和大家嘮叨一下，以后遇到比較棘手的問題，可以往這方面來靠攏
所有軟件的底層實現都是「操作和管理數據」。
無論是我們平時用到的桌面程序，亦或是在命令行中進行敲敲打打處理一些特定的操作，還有就是我們熟悉的編程開發中，無論是前端的開發過程中，使用原生也好，各種框架也罷，最后的根結都是數據的羅列和排布;還是后端就更明顯了，有SQL的操作，那就更是再「玩弄」數據。 之所以我們看到的現象有些不同，無非就是數據的表現形式和處理方式的不同。可以說，在編程界，--「萬物皆數據」。
這里簡單舉一個例子，日歷大家都見過哇。
如果，給我們一個需求，要讓我們實現一個飛書日歷或者google 日歷的開發任務，我們是不是一時感覺到無法下手。
那我們往「萬物皆數據」這個定論上靠，那是不是每一個「日程」（無論是簡單日程還是重復日程），它們本質上就是在每個小格子上展示。無非就是有的日程在單個格子上，有的日程是跨格子。 而針對這種情況，是不是就是在當前視圖中，我們需要維護一個數組，而這個數組中的項就是每個格子的示例。(針對月視圖/周視圖/日視圖的數據，其實都是一套，只不過在框架內部為我們提供了各自的展示邏輯)
這是一個開源的日歷庫(FullCalendar)。
圖片
而下面的events就是我們在日歷上顯示的日程信息。
圖片
好了，天不早了，干點正事哇。
「前置知識點」，只是做一個概念的介紹，不會做深度解釋。因為，這些概念在下面文章中會有出現，為了讓行文更加的順暢，所以將本該在文內的概念解釋放到前面來。「如果大家對這些概念熟悉，可以直接忽略」同時，由于閱讀我文章的群體有很多，所以有些知識點可能「我視之若珍寶，爾視只如草芥，棄之如敝履」。以下知識點，請「酌情使用」。
Git是一種用于源代碼管理的工具。它是一個免費且開源的版本控制系統，用于高效地處理從小型到非常大型的項目。Git用于跟蹤源代碼的更改，使多個開發人員能夠共同在非線性開發中合作。Git是由Linus Torvalds于2005年為Linux內核的開發而創建的。
在使用Git之前在維護代碼之前，團隊合作的模式如下：
圖片
它的典型代表為SVN
圖片
毋庸置疑，git是這方面的王者。
git commit -m “xxx” 就是「將 index 里的內容提交到本地倉庫中」
remote repository：是「遠程倉庫」，當我們使用git push命令時就會將本地倉庫的代碼上傳至遠程倉庫，完成整個代碼的上傳工作
圖片
git init --bare 和 git init 是兩種不同的Git初始化命令，它們用于創建不同類型的Git倉庫。
下面是它們之間的主要區別：
git init 默認創建一個帶有master分支的工作目錄倉庫。
git init --bare 默認不創建分支，因為裸倉庫不包含工作目錄。我們需要手動創建和設置分支。
一般情況下，如果我們需要創建一個新的Git倉庫用于開發和維護代碼，我們應該使用 git init。如果我們需要創建一個中央版本庫用于團隊協作和共享代碼，我們可以考慮使用 git init --bare。
鉤子（Hooks）是一種通用概念，通常用于「在特定事件發生時觸發自定義代碼」。雖然不是編程語言本身的一部分，但編程語言和開發工具通常提供一些機制來支持編寫和使用鉤子。
下面我們簡單介紹幾種大家比較常見的利用Hook概念的技術。
名稱 | 描述 | 示例語法 |
Git Hooks | Git 允許在代碼倉庫的特定事件上運行自定義腳本。事件包括提交、推送、合并等。 | 使用 Bash 腳本編寫，如 |
JavaScript Hooks | JavaScript 用于前端和后端開發，事件處理程序在特定事件發生時執行自定義 JavaScript 代碼。 | 前端中，事件處理程序如事件監聽器。后端中，使用 EventEmitter 模塊。 |
React Lifecycle Hooks | React 用于構建用戶界面，包括生命周期方法，允許在組件的不同生命周期階段運行自定義代碼。 | 生命周期方法如 當然，還有甚囂塵上的針對函數組件的 |
GitHub Webhooks | GitHub 提供 Webhooks，是 HTTP 回調，用于在存儲庫的特定事件上觸發自定義操作。 | 開發者編寫 Webhook 處理程序響應事件，配置 Webhook URL。 |
Jenkins Pipeline Hooks | Jenkins 是一個持續集成工具，允許創建自定義流水線腳本。使用鉤子定義流水線的階段和操作。 | 鉤子嵌入到 Jenkinsfile 中以定義流水線。 |
Git Hook是一種非常強大的Git自定義「腳本系統」，它允許我們在Git版本控制過程的不同階段執行自定義操作。這些操作可以是自動化測試、代碼格式化、驗證提交消息格式、預防性錯誤檢查等等。Git hooks是一種強大的自定義工具，可以提高代碼質量和協作效率。
「pre-commit」：在執行實際提交之前運行，用于執行「預提交檢查」。
「pre-push」：在執行實際推送之前運行，用于「驗證推送到遠程倉庫的內容」。
「pre-receive」：在接收端執行，通常用于「驗證推送到遠程倉庫的提交」。
「post-receive」：在接收端執行，通常用于「通知或自動化部署」。
git diff命令后通常需要跟兩個參數，參數1是要比較的舊代碼，參數2是要比較的新代碼。如果只寫一個參數，表示默認跟 workspace 中的代碼作比較。
?
git diff 顯示的結果為「第二個參數所指的代碼在第一個參數所指代碼基礎上的修改」
?
HEAD 指向的是 local repository 中的代碼最新提交版本
在Git中，別名（Git Aliases）是一種機制，允許我們為常用的Git命令或命令序列創建簡短的自定義命令。別名使我們可以用更短、更易記的名稱來執行常用的Git操作，提高工作效率。
「1. 創建別名：」 我們可以使用git config命令來創建Git別名。
git config --global alias.<alias-name> <git-command-or-sequence>「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值比較。
為了演示方便，我們在本地的合適的文件夾中新建了一個dot_git的項目。
mkdir dot_git與此同時通過git init來初始化項目。
圖片
現在讓我們來看看.git文件夾中有什么內容。
我們使用erd來查看文件結構。
erd -y inverted .git文檔結構如下
圖片
看起來它創建了一堆文件和文件夾。讓我們挑幾個重要的來解釋一下：
根據我們設置的“默認”分支是什么（git config --global init.defaultBranch <分支名稱>），它將是refs/heads/master(默認)，refs/heads/main，或者我們設置的其他分支名稱。
圖片
「它指向了refs/heads文件夾」，并指向一個叫做master的文件，這個文件在我們進行第一次提交之前是不存在的。
這個master文件「只會在我們進行第一次提交后出現」。
如果我們查看它，我們會看到一些關于我們的倉庫的基本設置，比如是否bare、文件模式等。
objects包含了Git對象，也就是關于倉庫中文件、提交等的「數據」。（這個狠最重要，狠重要）
refs，存儲引用（指針）的地方。
refs/heads包含分支的指針
refs/tags包含標簽的指針
現在，我們已經了解了.git目錄中初始文件的情況，讓我們執行第一個將內容添加到.git目錄的操作。我們將創建一個文件并將其添加到暫存區（但還沒有提交）。
echo 'hello,789' > filegit add file我們繼續使用erd -y inverted .git來查看文件變化。
圖片
git add file這會引起兩個主要的更改。
我們使用file來查看一下內容是何方神圣。
file .git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa.git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa: zlib compressed data結果顯示這是經過zlib壓縮的數據。這就很讓人抓馬。「你有張良計,我有過墻梯」，我們可以使用zlib庫對其解壓處理。
zlib-flate -uncompress < .git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aablob 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 | sha1sumc3dc8e6cf3e1117a8d9731ddde9916da644296aaGit使用內容的SHA-1散列值，取「前兩個字符」（在這種情況下是c3），創建一個文件夾，然后將剩余部分用作文件名。Git從前兩個字符創建文件夾，以確保我們不會在單個objects文件夾下有太多文件。
在Mac環境下，我們需要通過brew install md5sha1sum
由于objects的內容在Git中比較重要，Git還特意提供了一個名為git cat-file的命令，用于查看git對象的內容。 使用git cat-file命令
git cat-file -t c3dc8e6cf3e1117a8d9731ddde9916da644296aablobgit cat-file -s c3dc8e6cf3e1117a8d9731ddde9916da644296aa10git cat-file -p c3dc8e6cf3e1117a8d9731ddde9916da644296aahello,789既然，已經將內容通過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/masterfe010b33df5078cdbd96f2397aad60ec5f42a967看起來它指向了其中一個新對象。我們用內置命令cat-file查看內容。
$ git cat-file -t fe010b33df5078cdbd96f2397aad60ec5f42a967commit$ git cat-file -p fe010b33df5078cdbd96f2397aad60ec5f42a967tree 658524b859ae78d902597253a3b68b4da3b70466author xxx <xxx@simple> 1697178492 +0800committer xxx <xxx@xxx> 1697178492 +0800首次提交我們也可以使用以下命令查看該引用的類型：git cat-file -t refs/heads/master
看起來這是一種新的對象類型，似乎是一個「提交對象」（commit object）。提交對象的內容告訴我們，它包含一個哈希為658524b859ae78d902597253a3b68b4da3b70466的「樹對象」（tree object），這看起來就像我們在提交時添加的另一個對象。提交對象還包含了作者和提交者的信息。最后，它還顯示了這個提交的提交消息是什么。
我們繼續來看看樹對象包含了什么內容。
git cat-file -t 658524b859ae78d902597253a3b68b4da3b70466treegit cat-file -p 658524b859ae78d902597253a3b68b4da3b70466100644 blob c3dc8e6cf3e1117a8d9731ddde9916da644296aa file我們會發現該文件指向了在我們執行git add file時添加的原始對象(c3dc8e6cf3e1117a8d9731ddde9916da644296aa)。
圖片
樹對象內部使用更多的樹對象來表示文件夾，這些樹對象與提交對象相連，用于表示目錄結構。
讓我們對文件進行更改并查看它是如何工作的。
echo 'git,hello,789' > filegit ci -am "修改文件內容"還是利用erd查看文檔目錄
圖片
一個包含文件新內容的blob對象
一個是一個樹對象
最后一個是一個提交對象
讓我們再次從HEAD或refs/heads/master開始跟蹤它們。
git cat-file -p refs/heads/mastertree 02185c57f2040abcaa0c67dfd7026464d916da2bparent fe010b33df5078cdbd96f2397aad60ec5f42a967author 789 <789@xx> 1697179597 +0800committer 789 <789@xxx> 1697179597 +0800修改文件內容git cat-file -p 02185c57f2040abcaa0c67dfd7026464d916da2b100644 blob 1f9224976e282aa9e32398a5bca0cec08041f1dc filegit cat-file -p 1f9224976e282aa9e32398a5bca0cec08041f1dcgit,hello,789提交對象現在有一個額外的屬性，名為parent，它鏈接到「前一個提交」，因為這個提交是建立在前一個提交之上的。
這是Git中的提交歷史的關鍵概念，
每個提交都有一個或多個父提交，形成一個提交鏈。
是時候創建一個分支了。讓我們使用git br fix-text命令創建一個名為fix-text的分支。
前面講過，下面的br等同于branch。
圖片
這將在refs/heads文件夾下創建一個新文件，文件名為分支名稱，文件內容為最新提交的ID。
我們首先用git log查看提交記錄
圖片
發現最新的提交記錄為efa223e697c6452a393963887f9926ea0662c923
cat .git/refs/heads/fix-textefa223e697c6452a393963887f9926ea0662c923在Git中，分支是非常輕量級的。標簽（Tags）的行為也類似，只不過它們是創建在refs/tags下的。
還會在logs目錄下添加一個文件，用于存儲與主分支類似的提交歷史數據。這有助于跟蹤各個分支的提交歷史。Git的分支和標簽是非常有用的版本控制工具，可以幫助我們管理項目的不同狀態和版本。
在Git中，檢出（checkout）操作是獲取「提交」的樹對象，并將working tree中的文件更新為與樹對象記錄的狀態相匹配。
圖片
在這種情況下，因為我們從master切換到fix-text，而這兩個分支「都指向相同的提交和底層樹對象」，Git在working tree中沒有任何事情要處理。
前面講過，下面的co等同于checkout。
git co fix-text在.git目錄內執行co操作時，唯一的變化是.git/HEAD文件現在將指向fix-text。
cat .git/HEADref: refs/heads/fix-text另外，讓我進行一次提交。
echo 'hello,git' > filegit ci -am "更換文本內容"這將在fix-text分支上創建一個新的commit，將文件file中的內容更改為hello,git。
合并（merging）有主要三種方式。
在這種情況下，我們首先逐個將我們的更改應用到主分支（main或master）當前指向的每個提交，然后執行類似于快進合并的操作。
最后一種方式是通過創建一個獨立的合并提交來合并兩個分支。
這在于它將在其提交對象中有兩個父節點（parent entries）。
首先，讓我們看看在合并之前圖形是什么樣子。(先將分支切換回master(git co master))
git log --graph --oneline --all* 4359ab4 (fix-text) 更換文本內容* efa223e (HEAD -> master) 修改文件內容* fe010b3 首次提交執行合并操作
git merge fix-text更新 efa223e..4359ab4Fast-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 首次提交為了演示這一點，首先讓我創建另一個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歷史記錄所需的一切內容。
圖片
本文鏈接：http://www.tebozhan.com/showinfo-26-14703-0.html您有一篇Git 原理，請注意查收
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號