文章目錄Git 概述Git 的內容追蹤原理通過實際操作來理解第一種 object 類型commit第二種 object 類型tree第三種 object 類型blob第二次 commit用 reference 追蹤 commitTag總結Git 作為分布式版本管理工具的核心作用支撐多人協(xié)同開發(fā)云端托管項目。開發(fā)者可克隆倉庫至本地完成開發(fā)完成改動后推送至遠端主倉庫團隊成員同步拉取更新Git 完整記錄代碼迭代歷史支持任意版本回溯。我亦掌握git add、git push等基礎 Git 命令操作。日常開發(fā)中 95% 的場景僅需復用六七條基礎指令。其中兩項核心規(guī)范其一啟動新需求開發(fā)時務必基于開發(fā)分支新建特性分支并在該分支內完成全部開發(fā)工作其二嚴禁直接向生產分支提交推送任何代碼變更這條準則須嚴格恪守?！睂τ谖襾碚f日常高頻使用的指令git pull、git checkout、git add、git commit、git push 與 git merge。在實操過程中逐步吃透了commit的核心含義其等同于版本迭代歷程里的獨立快照節(jié)點同時也厘清了分支branch的底層邏輯 —— 分支是從指定提交節(jié)點衍生出的獨立開發(fā)鏈路。在長期開發(fā)實踐中開發(fā)者會接觸到各類進階指令例如 git reset、git revert同時掌握 git stash、git cherry-pick 等高階操作技巧。多數(shù)從業(yè)者可熟練運用 Git 完成多人員協(xié)同開發(fā)工作但對工具后臺運行機制缺乏認知。為此有必要深入學習 Git 底層數(shù)據(jù)模型厘清工具內部運行原理。充分掌握 Git 底層運行機制后各類操作邏輯將形成完整閉環(huán)。本文旨在跳出機械套用指令的淺層使用模式完整拆解 Git 內部底層運行原理。Git 概述首先參考 Git 官方文檔給出的標準定義。補充說明使用 Git 工具前需完成本地環(huán)境安裝未部署該工具的使用者可前往 Git 官方網站獲取安裝程序。下文將援引官方文檔內容梳理 Git 的標準釋義。官方文檔首頁Git 的自我描述:NAMEgit- the stupid content tracker依據(jù) Git 官方標準定義Git 是一款高效、可拓展的分布式版本控制系統(tǒng)具備完備豐富的指令體系既支持上層封裝操作亦開放完整底層接口供使用者調取內部運行機制。剝離上層功能封裝Git 的核心本質可概括為內容追蹤工具( A tool to track content)。這是理解該工具的關鍵認知要點。大眾普遍存在固有認知即 Git 僅適用于軟件開發(fā)項目該認知存在局限性。Git 的核心能力為追蹤任意類型文件內容適用范圍不受軟件代碼限制。該基礎認知看似淺顯卻能夠直觀反映使用者普遍存在的知識盲區(qū)多數(shù)使用者僅掌握表層操作并未真正理解 Git 底層核心邏輯。Git 的內容追蹤原理可將 Git 的底層存儲機制抽象為一套鍵值映射體系體系中以唯一鍵匹配對應數(shù)據(jù)映射中的值為各類文件轉化后的二進制字節(jié)流。當一段數(shù)據(jù)存入 Git 時系統(tǒng)會對其完成持久化存儲并借助 SHA-1 哈希算法生成專屬哈希鍵。哈希鍵是一段固定長度的摘要字符串可唯一標識大塊數(shù)據(jù)Git 依靠該索引區(qū)分倉庫內所有已存儲內容。哈希值的生成結果不受設備、操作系統(tǒng)影響只要兩段數(shù)據(jù)內容完全一致無論在任何環(huán)境下計算最終產出的哈希鍵必然相同。該特性是掌握 Git 底層邏輯的關鍵認知。通過實際操作來理解我準備創(chuàng)建一個項目用來管理我家人的任務。讓我們初始化一個 Git 倉庫repository// Initialize an empty Git repository inside tech-lab folder $gitinit tech-lab // Open tech-lab folder $cdtech-lab // Examine .git folder $ls.git HEAD config description hooks/ info/ objects/ refs/執(zhí)行倉庫初始化操作后Git 將自動生成隱藏目錄 .git該目錄內含多組配套文件與子目錄。本節(jié)重點說明 objects 目錄此目錄為 Git 的對象數(shù)據(jù)庫。項目所有版本快照對應的存儲對象均統(tǒng)一生成并存放于該目錄中。$ls.git/objects info/ pack/objects 目錄下內置 info 與 pack 兩個子目錄二者服務于 Git 底層存儲優(yōu)化邏輯現(xiàn)階段無需深究。未存入任何內容時objects 目錄默認處于空目錄狀態(tài)。接下來向當前項目中新增首個文件# 創(chuàng)建 Plants.txt 文件寫入內容 Rose$printfRosePlants.txt#使用cat查看文件內容catPlants.txt Rose#查看新增文件后的倉庫當前狀態(tài)$gitstatus On branch master No commits yet Untracked files:(usegit add file...to includeinwhat will be committed)Plants.txt nothing added to commit but untracked files present(usegit addto track)Git 在這里告訴我們的是我們有一些文件處于未跟蹤untracked狀態(tài)。這些文件存在于 Git 所稱的 工作目錄Working Directory 中。如果我們希望將這些更改添加到下一次 commit提交 中就必須先將它們添加到一個中間區(qū)域intermediary area。將新增或修改的文件添加到暫存區(qū):$gitadd.執(zhí)行該指令并不會生成提交記錄亦不會將變更寫入版本歷史。該命令的本質意圖可表述為告知 Git 對目標文件開啟跟蹤持續(xù)記錄其后續(xù)改動。這個用于存放已跟蹤文件的第二個區(qū)域稱為 Staging Area暫存區(qū)它的技術名稱是 index。若確認僅以當前全部變更生成commit并且不包含其他任何更改則暫存區(qū)內所有已登記變更均會作為新commit的組成內容。創(chuàng)建一個commit,信息(message)為“create plants file”的新commit$gitcommit-mcreate Plants file1filechanged,1insertion()create mode100644Plants.txt此時產生了何種底層變化其一本次操作生成了第一條 commit。除此之外系統(tǒng)還將在 objects repository 的 objects/ 目錄中生成若干內部存儲對象?？蛇M入目錄進行核查$ ls .git/objects 01/ ab/ cf/ info/ pack/除原有 info/、pack/ 子目錄外objects 目錄下新增了三類對象文件。在此之前需明確 Git 包含三種基礎對象類型blob、tree 與 commit下文將結合當前示例依次闡釋各類對象的定義與作用。接下來逐層解析新增對象的內部結構首先從本次生成的 commit 對象入手顯示commit log:$gitlog commit 016e263a1b9b430cf0b1044b59d8e66d57ccc58c(HEAD -master)Author: plants-labplants-lablab.comDate: Sat Aug1521:54:5620260700 create Plantsfile本次生成的首個 commit 哈希值為 :016e263a1b9b430cf0b1044b59d8e66d57ccc58c觀察 objects/ 目錄下新增的子目錄能夠發(fā)現(xiàn)存在名為 f6/ 的文件夾命名取自該哈希值的前兩位字符。進入該目錄查看內部存儲內容:$ls.git/objects/01 6e263a1b9b430cf0b1044b59d8e66d57ccc58c01/ 文件夾中的文件名正好等于構成該 commit 的 hash key 的其余字符。01/6e263a1b9b430cf0b1044b59d8e66d57ccc58c016e263a1b9b430cf0b1044b59d8e66d57ccc58c需留意對象數(shù)據(jù)庫的存儲命名規(guī)則objects 目錄下新建子目錄名稱取自哈希值前兩位字符子目錄內文件名稱則為哈希鍵剩余字符。該套命名約定naming convention是 Git 內置的數(shù)據(jù)存儲規(guī)范以此結構存儲可大幅提升對象objects檢索效率。該文件即為對象數(shù)據(jù)庫中與本次 commit 相對應的 object。第一種 object 類型commit該 object 的內部結構與存儲內容如何查看可借助底層 Git 命令low-level Git commandcat-file該指令能夠輸出倉庫repository內任意 object 的類型與原始內容。查看object類型$gitcat-file 016e263a1b9b430cf0b1044b59d8e66d57ccc58c-tcommit查看object類容$gitcat-file 016e263a1b9b430cf0b1044b59d8e66d57ccc58c-ptree cf88f5f0c0482b8948fec42bc85bcf23875e12fd author plants-labplants-lablab.com17868056960700 committer plants-labplants-lablab.com17868056960700 create Plantsfile這便是 commit 的內部結構對應前文剛生成的commit記錄。commit 本質為純文本數(shù)據(jù)。與 Git 內所有存儲內容一致該文本會先完成壓縮處理再生成專屬 hash最終持久化存入 objects repository。commit object 內部存儲各類 metadata 元數(shù)據(jù)涵蓋 author、committer、commit date 以及 commit message。除此之外該 commit 中還記錄了一條 tree 及其對應的 hash key。沿用檢索 commit hash key 的方式查詢此 tree 的 hash key能夠證實倉庫repository內存在匹配該哈希標識的 object。$ls.git/objects/ 01/ ab/ cf/ info/ pack/ $ls.git/objects/cf/ 88f5f0c0482b8948fec42bc85bcf23875e12fdcf/88f5f0c0482b8948fec42bc85bcf23875e12fdcf88f5f0c0482b8948fec42bc85bcf23875e12fd這個 object 就是 object database 中對應于這個 tree 的 object第二種 object 類型treetree 是用于存儲項目 directories目錄信息的 object。單個 tree 可引用其他 tree以此 build 出完整的文件與子目錄 hierarchy層級結構同時也能夠指向 blob。每一條 commit 都會關聯(lián)一個 tree object該 tree object 會以完整 snapshot快照的形式capture 當前 commit 執(zhí)行瞬間整個 repository 的全部狀態(tài)。這份 snapshot 便是存入 Git historyGit 歷史記錄的項目版本。接下來查看 tree 的內部結構$gitcat-file cf88f5f0c0482b8948fec42bc85bcf23875e12fd-ttree $gitcat-file cf88f5f0c0482b8948fec42bc85bcf23875e12fd-p100644blob ab0d218b097a7cb260b99336411779a703a672e1 Plants.txt輸出內容解釋字段值含義模式100644文件權限模式100644 表示普通文件非可執(zhí)行即 -rw-r–r–類型blob說明這個條目是一個文件內容對象blob不是子目錄tree哈希ab0d218b…這個文件內容對應的 SHA-1可以用 git cat-file -p ab0d218b… 繼續(xù)查看 Plants.txt 的實際內容文件名Plants.txt該 blob 在這個目錄tree里的名字tree object 內部以單行記錄單個文件或子目錄信息每條記錄會依次存儲 permissions權限、object type對象類型、object hash 以及 filename文件名。文件名由 tree object 統(tǒng)一管理而非文件自身的 blob 內容決定。下文將對該特性的原理展開說明。當前 tree 中存在一條指向 blob object 的 引用前往 objects 數(shù)據(jù)庫檢索即可確認就會發(fā)現(xiàn)這個第三個 object 確實存在于其中$ls.git/objects 01/ ab/ cf/ info/ pack/ $ls.git/objects/ab/ 0d218b097a7cb260b99336411779a703a672e1最后我們來查看第三種 object 類型blob 的內部結構$gitcat-file ab0d218b097a7cb260b99336411779a703a672e1-tblob $gitcat-file ab0d218b097a7cb260b99336411779a703a672e1-pRose第三種 object 類型blobBlob 是 binary large object二進制大對象的縮寫用于存儲文件原始數(shù)據(jù)不攜帶任何與文件相關的 metadata其中也不含 filename。文件的每一個版本都由獨立 blob 承載?？偨YGit 包含三類基礎 objectblobs、trees、commits。Git 會為每一類 object 計算專屬 SHA-1 hash 作為唯一 key隨后將對象內容壓縮并持久化存入 repository。一條 commit 會關聯(lián)一個 tree object該 tree 以 snapshot快照形式 捕獲repository 在對應時間點的完整狀態(tài)tree 可引用 blob也可嵌套指向其他 tree以此搭建完整 層級結構blob object 僅單純存儲文件字節(jié)內容無額外附屬信息。開發(fā)流程中生成的每一條 commit 均遵循上述存儲邏輯對應 object 會統(tǒng)一存入 Git 的 object database這便是 Git 存儲、管理項目內容的底層實現(xiàn)機制。本次首個 commit 對應的對象關系圖------------------------------ -------------------------------------- ----------------------------------|commit 016e263...||tree cf88f5...||blob ab0d21...|------------------------------ -------------------------------------- ----------------------------------|tree cf88f5...||modetypeobject name||content(Plants.txt):||author plants-lab|------|--------------------------------------|------|||committer plants-lab||100644blob ab0d21... Plants.txt||Rose||date2026?08?1215:30:00||||||||||...||Initial commit||............||(文件內容的二進制數(shù)據(jù))|------------------------------ -------------------------------------- ----------------------------------- commit提交對象 tree樹對象 blob對象 記錄一次提交的信息包含作者、提交者、 記錄目錄結構。每一行代表一個文件或子目錄 保存文件的實際內容二進制數(shù)據(jù) 時間、提交說明等并指向一個 tree 對象。 包含權限、類型、對象哈希和文件名。 不包含文件名或任何元數(shù)據(jù)。 可以指向 blob文件或其他 tree子目錄。 ---------------------------------------------------------------------------------------------------|字段說明:mode權限type類型(blob文件,tree目錄)object對象的 SHA?1 哈希name文件名/目錄名|---------------------------------------------------------------------------------------------------|關系: commit 指向 tree -tree 指向 blob 或其他 tree -blob 保存文件內容|---------------------------------------------------------------------------------------------------我們先前還留有一個懸而未決的問題在探討 trees 與 blobs 的機制時這個問題至關重要為什么文件名是存放在 tree 之中而不是存放在 blob 里這個問題的答案可以說是理解 Git 過程中最重要、最讓人恍然大悟的關鍵之一。第二次 commit首先我們在項目的根目錄下新增一個名為 tasks/ 的文件夾。在其中為每個任務創(chuàng)建一個文件并以負責該任務的人員姓名作為文件名。第一個任務是plants trees而負責這項任務的人是我。$mkdirtasks $printfRose./tasks/plant_trees.txt $gitadd.$gitcommit-mCreate plant the trees task[master ff1080d]Create plant the trees task1filechanged,1insertion()create mode100644tasks/plant_trees.txt我們剛剛新增了一條 commit按照前面學到的知識objects 數(shù)據(jù)庫目錄里理應生成了一批新對象。接下來我們就來看看具體新增了哪些內容。和第一次提交時一樣我們先查看這個全新的 commit。這次我們使用 Git 的 --oneline 參數(shù)將每一條 commit 的信息做精簡展示。$gitlog--onelineff1080d(HEAD -master)Create plant the trees task 016e263 create Plantsfile$gitcat-file ff1080dc44bc51d20bde8432ed5f4630b3c2fe5e-tcommit $gitcat-file ff1080dc44bc51d20bde8432ed5f4630b3c2fe5e-ptree c652f10626f677c9452fdfeb4579fec8afced0a0 parent 016e263a1b9b430cf0b1044b59d8e66d57ccc58c author plants-labplants-lablab.com17868875760700 committer plants-labplants-lablab.com17868875760700 Create plant the trees task我們得到了第二個 commit 預期的內容但同時也發(fā)現(xiàn)了一個新的要素。這個 commit 里面包含了一個 parent 對象。那么這個 parent 對象到底是什么呢它其實就是我們的第一個 commit。你可以對比兩者的 ID以此來驗證這一點。除了第一個 commit 以外其余所有 commit 都至少擁有一個 parent commit。現(xiàn)在我們再來看看 tree 容器$gitcat-file c652f10626f677c9452fdfeb4579fec8afced0a0-ttree $gitcat-file c652f10626f677c9452fdfeb4579fec8afced0a0-p100644blob ab0d218b097a7cb260b99336411779a703a672e1 Plants.txt 040000 tree a59dc4bb5f187af5549111d0fee48578bee3ecd7 taskstree 內部包含兩組對象引用和上一個 commit 完全相同的 blob 引用對應文件 Plants.txt一個全新的 tree 引用對應目錄 Tasks前面我們提到過tree 的職責就是搭建項目的目錄層級結構。本次我們向項目新增了一個文件夾出現(xiàn)這個新 tree 對象也就不難理解。指向 Plants.txt 的 blob 引用沒有任何改動也就代表該文件對應的實際內容完全沒有發(fā)生變化。$gitcat-file ab0d218b097a7cb260b99336411779a703a672e1-tblob $gitcat-file ab0d218b097a7cb260b99336411779a703a672e1-pRose讓我們一起來查看這個全新的 tree 對象$gitcat-file a59dc4bb5f187af5549111d0fee48578bee3ecd7-ttree $gitcat-file a59dc4bb5f187af5549111d0fee48578bee3ecd7-p100644blob ab0d218b097a7cb260b99336411779a703a672e1 plant_trees.txt正如我們預料的那樣這個 tree 中保存著一個 blob 對象的 ID該條記錄的引用名稱為Plant_trees.txt。最后我們再來查看這個 blob 對象內部的實際內容。$gitcat-file ab0d218b097a7cb260b99336411779a703a672e1-tblob $gitcat-file ab0d218b097a7cb260b99336411779a703a672e1-pRose這里出現(xiàn)了一個很有意思的現(xiàn)象:plant_trees.txt對應的 blob 對象 ID和 Plants.txt 的 blob ID 是一模一樣的。兩個完全獨立的文件對象 ID 按理來說不應當是唯一的嗎事實上這并不是簡單的重復只是 Git 在對已有數(shù)據(jù)做高效復用。Git 檢測到這兩份文件的內容完全一致于是它并不會在數(shù)據(jù)庫中生成兩份一模一樣的對象而是只創(chuàng)建一個 blob 對象讓兩處引用同時指向這同一個 blob。Git 的內部邏輯大致是這樣“假如對象庫中已經存在這份壓縮好的內容沒必要再保存一份一模一樣的對象。直接復用這個對象讓不同 tree 里的條目都指向同一個 blob 就可以?！币虼酥灰獌热萃耆恢翯it 就會生成完全相同的哈希 key。眼前這個場景正是該規(guī)則的實際體現(xiàn)。Git 有一條底層命令 hash?object接收一段內容返回對應的 hash key。我們可以通過管道傳遞內容加上 --stdin 參數(shù)讓命令從標準輸入讀取字符串。我們示例中的這兩個文件內容都是 Rose?，F(xiàn)在我們把字符串 Rose 交給 Git看看會得到什么結果$printfRose|githash-object--stdinab0d218b097a7cb260b99336411779a703a672e1我們得到了完全一樣的 hash key。意味著如果我們再新建一個內容為 Rose 的 txt 文件新的 commit 同樣會指向這同一個 blob。Git 對對象數(shù)據(jù)庫里的對象做了極高效率的管理只要內容一致就會直接復用已有的 blob文件處在哪個目錄下并不會對此產生任何影響。這也解釋了為什么文件名要存放在 tree 對象當中。正是這樣的設計才允許不同文件名共同引用同一個 blob。Git 遠比我最初想象的要巧妙。下面就是第二個 commit 的對象關系圖┌─────────────────────────────┐ ┌─────────────────────────────┐ ┌─────────────────────────────┐ │ commit ff1080..│ │ tree c652f..│ │ blob ab0d21..│ ├─────────────────────────────┤ ├─────────────────────────────┤ ├─────────────────────────────┤ │ tree c652f..│-------│ blob ab0d21..Plants.txt │------│ contentRose│ │ parent 016e26..│ │ tree a59dc4..Tasks │ │ │ │ author plants_lab..│ └─────────────────────────────┘ └─────────────────────────────┘ │ committer plants_lab..│ ↓ ↑ └─────────────────────────────┘ └──────────────────┌───────────────────────────────┐ │ tree a59dc4..│ ├───────────────────────────────┤ │ blob ab0d21..Plant_trees.txt │ └───────────────────────────────┘最后這就是兩個 commit 的 對象關系圖它們在 objects database 中共享同一個 blob。┌─────────────────────────────┐ ┌─────────────────────────────┐ ┌─────────────────────────────┐ │ commit ff1080..│ │ tree c652f1..│ │ tree a59dc4..│ ├─────────────────────────────┤ ├─────────────────────────────┤ ├──────────────────────────────┤ │ tree c652f1..│-------│ blob ab0d21..Plants.txt │ ------│ blob ab0d21..Plant_trees.txt │ │ parent 016e26..│ │ tree a59dc4..tasks │ └──────────────────────────────┘ │ author plants_lab..│ └─────────────────────────────┘ ↓ │ committer plants_lab..│ ↓ ↓ └─────────────────────────────┘ └──────────────────────┌───────────────────────────┐ ↓ │ blob ab0d21..│ ↓ ├───────────────────────────┤ ┌─────────────────────────────┐ ┌──────────────────────────┐ │ contentRose│ │ commit 54725f..│ │ tree cf88f5..│---└───────────────────────────┘ ├─────────────────────────────┤ ├──────────────────────────┤ │ tree cf88f5..│-------│ blob ab0d21..Plants.txt │ │ author plants_lab..│ └──────────────────────────┘ │ committer plants_lab..│ └─────────────────────────────┘2 個 commit、3 個 tree但只有 1 個 blob。用 reference 追蹤 commit我們再回到第二個 commit。可以看到這里出現(xiàn)了一個名為 parent 的全新對象它是指向父commit的引用。正是依靠這個引用Git 才得以維護提交的先后歷史順序。Git 通過各個 commit 串聯(lián)形成一條提交鏈。只要掌握每個 commit 的hash key我們就可以隨時回到項目過去任意一個歷史狀態(tài)。但哈希是一個 40 位的十六進制數(shù)字對人來說很難記憶。相比一串隨機字母與數(shù)字組成的字符串我們更容易記住帶有實際語義的單詞。為此 Git 提供了可讀性更好的引用references幫助我們擺脫冗長哈希的記憶負擔。我們打開倉庫根目錄下的 refs/ 文件夾看看示例環(huán)境中這里存放了什么內容。$ls.git/refs/ heads/ tags/在 refs/ 文件夾內部包含 heads/ 和 tags/ 兩個子目錄。我們先來打開 heads/ 文件夾查看其中的內容$ls.git/refs/heads/ master這就是我們的 master 分支branch。Git 在我們初始化 repository 的那一刻就創(chuàng)建了這個分支。讓我們創(chuàng)建一個新的分支$gitcheckout-bbranchA Switched to a new branchbranchA$ls.git/refs/heads/ branchA master分支branches本質上就是引用references所有分支都存放在 refs/ 目錄下的 heads/ 文件夾中。一個分支在磁盤上的物理形態(tài)究竟是什么?$cat.git/refs/heads/master ff1080dc44bc51d20bde8432ed5f4630b3c2fe5e一個 branch 本質上就是一個 hash。它就是第二個 commit 的 hash。一個 branch 就是一個指向 commit 的指針pointer只是它擁有一個對人類更友好的名稱。說得更簡單一點一個 branch 本質上就是一個文件文件里面存放著一個字符串而這個字符串就是 commit 的 hash key。借助 Git 的 branch我們可以在 commit 歷史中非?？焖俚厍昂笄袚Q也就是在項目的不同歷史狀態(tài)之間來回移動。$cat.git/refs/heads/branchA ff1080dc44bc51d20bde8432ed5f4630b3c2fe5e如果我們讀取 branchA 的內容會發(fā)現(xiàn)它的哈希 key 和 master 完全一致。這是因為該分支從 master 分支創(chuàng)建出來之后還沒有產生過任何新的 commit。這兩個指針此刻同時指向同一個 commit。那么it 又是如何判斷我們當前正處于哪一個分支呢Git 會把這個信息保存在倉庫根目錄下的 HEAD 文件當中。$cat.git/HEAD ref: refs/heads/branchA這個文件里面存放的并不是哈希值正如前面所說只有 object database 中的 objects 才擁有 hash。分支本身并不是對象它們屬于引用而 HEAD 指向的恰恰是一個分支。所以HEAD 存儲的是對另一個 reference 的引用。簡單做個總結HEAD 是一個指向其他指針的指針。我們也可以這樣來理解這層關系┌──────┐ ┌────────┐ ┌─────────────────────────────┐ ┌────────┐ │ HEAD │----│branchA │------│ commit ff1080..│ ←------│ master │ └──────┘ └────────┘ ├─────────────────────────────┤ └────────┘ │ tree c652f1..│ │ parent 016e26..│ │ author plants_lab..│ │ committer plants_lab..│ └─────────────────────────────┘ │ ▼ ┌─────────────────────────────┐ │ commit 016e26..│ ├─────────────────────────────┤ │ tree cf88f5..│ │ author plans_lab..│ │ committer plants_lab..│ └─────────────────────────────┘讓我們創(chuàng)建一個新的commit看看會發(fā)生什么$gitbranch * branchA master $printfRosetasks/plant_shop.txt $gitadd.$gitcommit-mcreate plant_shop task[branchA 7f1598b]create plant_shop task1filechanged,1insertion()create mode100644tasks/plant_shop.txt讓我們檢查一下引用的當前值$cat.git/refs/heads/master ff1080dc44bc51d20bde8432ed5f4630b3c2fe5e $cat.git/refs/heads/branchA 7f1598bf66023ef3e20caa9bcbca473edacfc48d $cat.git/HEAD ref: refs/heads/branchA整個過程可以概括為新的 commit 創(chuàng)建后branchA 的值會隨之更新因為它現(xiàn)在指向了這個新的 commit。此時branchA 是當前分支current branch。HEAD 文件不會發(fā)生變化它仍然指向 branchA。master branch 不會發(fā)生變化仍然保持原來的 hash。┌──────┐ ┌────────┐ ┌─────────────────────────────┐ │ HEAD │----│branchA │-------------------│ commit 7f1598..│ └──────┘ └────────┘ ├─────────────────────────────┤ │ tree b544ff..│ │ parent ff1080..│ │ author plants_lab..│ │ committer plants_lab..│ └─────────────────────────────┘ │ ▼ ┌─────────────────────────────┐ ┌────────┐ │ commit ff1080..│ ←----- │ master │ ├─────────────────────────────┤ └────────┘ │ tree c652f1..│ │ parent 016e26..│ │ author plants_lab..│ │ committer plants_lab..│ └─────────────────────────────┘ │ ▼ ┌─────────────────────────────┐ │ commit 016e26..│ ├─────────────────────────────┤ │ tree cf88f5..│ │ author plants_lab..│ │ committer plants_lab..│ └─────────────────────────────┘Tag我們最后一種 reference 是 tag。tag 是一種特殊的 reference引用用于在 commit 歷史中標記某個 commit。它和 branch 有些相似但兩者有一個關鍵區(qū)別tag 和 branch 的主要區(qū)別在于commit 創(chuàng)建之后tag 不會改變它的值。tag 是一個指向特定 commit 的不可變引用immutable reference。注意tag 主要用于標記代碼的發(fā)布版本release version。這樣無論什么時候通過這個 tag 獲取代碼都能得到與該版本發(fā)布時完全相同的 snapshot。Git Tag vs Branch 對比特性Branch分支Tag標簽本質會自動移動的指針固定不變的引用新增 commit 后會怎樣自動往前移動指向最新 commit不會移動永遠指向打標簽那一刻的 commit代表的含義“現(xiàn)在進行到哪了”動態(tài)進度“某個特定的歷史節(jié)點”固定時刻典型用途日常開發(fā)、功能迭代如 main、dev、feature/xxx標記版本發(fā)布點如 v1.0.0常用命令:git branch 、git checkout git tag 、git tag |簡單示例:# 分支會跟著新的 commit 移動main → commitAgitcommit-m新功能main → commitB# main 自動更新指向最新的# tag 一旦打上永遠固定gittag v1.0# v1.0 → commitAgitcommit-m新功能v1.0 → commitA# tag 依然指著原來那個不會變main → commitB# 只有 main 分支往前移動了讓我們創(chuàng)建一個 tag。它會被保存在 refs/ 目錄下的 tags/ 子目錄中。$gitbranch * branchA master $gittag v1.0 $cat.git/refs/tags/v1.0 7f1598bf66023ef3e20caa9bcbca473edacfc48d如同我們看到的tag v1.0 本質上只是一個指向某個 commit 的指針——也就是當前這個 commit。即使以后項目不斷發(fā)展branchA 已經沿著 commit 歷史向前推進了很多我們仍然可以通過 tag v1.0 快速回到這個 commit 所對應的項目狀態(tài)?？偨Y讓我們總結一下本文最重要的 5 個要點Git 在 object database 中存儲三種類型的 objectcommits、trees 和 blobs。Git database 中的每個 object 都有一個與之關聯(lián)的 hash key。Git 利用 commits、trees 和 blobs并使用它們的 hash key 作為指針高效地構建項目的數(shù)據(jù)層級結構同時避免重復存儲相同的內容。Hash key 很難被人類記憶因此 Git 提供了一種更友好的方式來引用這些 hashreferences引用。我們有 branches、HEAD 和 tags。branch 是一個指向 commit 的指針。Git 默認的 branch 名稱是 master但你可以創(chuàng)建任意數(shù)量的 branch。HEAD reference 告訴我們當前正在使用哪個 branch。每當創(chuàng)建一個新的 commit 時branch 指針都會自動向前移動。最后tag reference 是不可變的immutable它始終指向同一個 commit因此可以用來永久標記某個時間點的項目狀態(tài)。