2017 年 8 月

第 32 卷,第 8 期

本文章是由機器翻譯。

DevOps - Git 內部運作:架構與索引檔

Jonathan Waldman |2017 年 8 月

在 [我的最後一篇文章 (msdn.com/magazine/mt809117),我示範了如何 Git 會使用有向非循環圖 (DAG) 來組織的儲存機制認可物件。我也已探索的物件可以參考到哪一個認可的 blob、 樹狀結構和標記物件。我結束之發行項的簡介分支,包括標頭和 head 之間的差別。該發行項是這一個,在其中要探討 Git"三個樹狀結構 」 架構的重要性以及及其索引檔的必要條件。了解這些其他的 Git 內部項目會建置在可讓您更有效的 Git 使用者也會提供新的深入資訊,當您瀏覽各種 fronted 由 Visual Studio IDE 中工具的圖形化 Git 的 Git 作業的基本知識。

正如最後一篇文章 Visual Studio 通訊搭配 Git 使用 Git 應用程式開發介面,而且 Visual Studio IDE Git 工具離開摘要的複雜性和基礎 Git 引擎功能。這是一大的開發人員想要實作版本控制工作流程,而不需依賴 Git 命令列介面 (CLI)。還有,否則很有幫助的 Git 抽象概念,在 IDE 的可能有時會造成混淆。例如,ponder 專案加入 Git 原始檔控制、 修改專案檔、 暫存它們並再認可執行的檔案的基本工作流程。若要這樣做,請開啟 Team Explorer 變更窗格,即可檢視變更的檔案清單,然後選取您想要的階段。中最左邊的映像,請考慮圖 1,其中顯示我已變更的工作目錄中的兩個檔案 (標記 1)。

[Team 總管] 變更窗格可以在其變更和暫存的變更區段顯示相同的檔案

圖 1 Team 總管] 變更窗格可以在其變更和暫存的變更區段顯示相同的檔案

在右邊下一個圖中,我接移一個變更的檔案:Program.cs (標記 2)。當我這樣做時,Program.cs 會出現 「 已 「 從變更清單轉換成分段的變更清單。如果我進一步修改,然後儲存 Program.cs 的工作目錄的副本,它會繼續出現在分段的變更 > 一節 (標記 3),但它也會出現在 [變更] 區段 (標記 4) ! 如果不了解 Git 執行在幕後,您可能會 flummoxed 直到您說,找出有兩個 「 複本 」 的 Program.cs: 一個在工作資料夾,一個物件的 Git 內部資料庫中。即使您了解,您可能沒有任何有用的資訊時 unstage 暫存的複本會發生什麼事,嘗試暫置 Program.cs 的第二個已變更的副本、 復原工作複本的變更,或切換分支。

真正抓住 Git 做為您的階段、 unstage、 復原、 認可並簽出檔案,您首先必須了解 Git 架構的方式。

Git 三樹狀架構

Git 實作 (在此內容中的 「 樹 」 指的目錄結構和檔案) 的三個樹狀架構。使用從左到右中圖 2 Git 三樹狀架構會運用其智慧和有效率 Performance2 檔案進行 All-Important 索引,第一個樹狀結構的工作目錄中檔案和資料夾集合-OS 目錄包含隱藏的.git 資料夾; 第二個樹狀結構通常儲存在單一的二進位檔稱為.git 資料夾的根目錄中的索引; 第三個樹狀結構組成表示 DAG (請記得 Git 物件SHA 1 命名 Git 物件位在兩個十六進位的數字-命名的資料夾。 git\objects,而且也可以儲存在位於.git\objects\pack 和.git\objects\info\alternates 檔案所定義的檔案路徑中的 「 組件 」 檔案)。請記住,Git re po 定義所有的檔案該 sit.git 資料夾中。通常,人員參考 Git 儲存機制中,為 DAG,並且不是很精確:索引和 DAG 兩者都包含在 Git 儲存機制。

Git 三個樹狀結構會進行 All-Important 索引檔案利用其智慧且有效率的效能

圖 2 Git 三個樹狀結構會進行 All-Important 索引檔案利用其智慧且有效率的效能

請注意,每個樹狀結構會儲存目錄結構和檔案,而每個會利用 re 保留特定樹狀結構的中繼資料及最佳化儲存和擷取的順序不同的資料結構。第一個樹狀結構 (工作目錄樹狀結構,也稱為 「 工作樹狀目錄 」) 是清楚的作業系統檔案和資料夾 (沒有特殊的資料結構,而不是什麼是作業系統層級),並符合需求的軟體開發人員和 Visual Studio;第二個樹狀目錄 (Git 索引) 會跨越工作 di rectory 和形成 DAG,藉此協助執行快速的工作目錄的檔案內容比較和快速認可; Git 認可物件第三個樹狀目錄 (DAG) 可讓追蹤 histoa 強大的版本控制系統的 Git、 Git 將很有幫助的中繼資料加入至其儲存在索引和認可物件中的項目。例如,它會儲存在索引中的中繼資料可協助它時它會存放在認可物件的中繼資料,可協助它追蹤誰發出 「 認可和何種原因,在工作目錄中,偵測檔案的變更。

若要檢閱三個樹狀結構中的三個樹狀結構,並將某些檢視方塊周圍的這篇文章的焦點其餘部分:您已經知道工作目錄樹狀結構的運作方式,因為它是實際的作業系統檔案系統您已經精通中使用。而且如果您閱讀我之前的文章,您應該已經很好的 DAG 的實用知識。因此,此時,遺失的連結是跨越工作目錄和 DAG 在索引樹狀結構 (之後,「 索引 」)。事實上,索引會播放這類重要角色,則這篇文章的其餘部分的唯一主體。

索引的運作方式

您可能聽易記的建議索引是與 「 臨時區域 」。 雖然這有點正確,請說出它,這樣一來與它,則為 true 的角色,這是支援臨時區域,不僅有助於 Git 能夠偵測您的工作目錄; 中的檔案的變更若要我-diate 分支合併處理,讓您可以解決衝突的檔案為基礎,並安全地中止合併在任何時間;並將執行的檔案和資料夾轉換成樹狀結構的下一個認可物件寫入其參考的物件。Git 也使用索引來保留資訊擷取自 DAG 的物件以及相關的工作樹狀結構中的檔案,並因此做為類型快取的進一步利用索引。讓我們更徹底調查索引。

索引實作其自己獨立的檔案系統,讓它能夠儲存資料夾和檔案,以及其相關的中繼資料的參考。如何及何時 Git 更新此 dex 中取決於發行的 Git 命令和指定的命令選項的種類 (如果您因此需要,您可以也使用 Git 更新索引配管命令自行管理索引),因此這裡完整涵蓋範圍未 pos sible。不過,當您使用 Visual Studio Git 工具時,它是要注意的主要方式 Git 更新索引並 Git 會使用儲存在索引中的資訊很有幫助。圖 3顯示 Git 與工作目錄資料,當您暫存檔案,且它會更新索引 DAG 資料與您起始的合併 (如果有合併衝突)、 複本或提取時,更新索引,或切換分支。相反地,Git 會依賴儲存在索引中後發出認可、 更新 DAG 時和在更新的工作目錄之後再製, 或提取時或之後切換分支的資訊。一旦您了解 Git 依賴索引和索引跨越許多 Git 作業,開始,您將進入修改索引中,ad vanced Git 命令有效地讓您人士 Git 的運作方式的技巧。

主要的 Git 動作

圖 3 更新索引 (綠色) 的主要 Git 動作,並依賴哪些索引的 Git 動作包含 (紅色)

若要查看在寫入至索引,它會發生什麼情況的工作目錄中,我們來建立新的檔案。只要您暫存檔案時,Git 會建立標頭使用這個字串串連公式:

blob{space}{file-length in bytes}{null-termination character}

Git 接著會將檔案內容的開頭的標頭。因此,對於包含字串"Hello"文字檔案,標頭 + 檔案的內容仍會產生看起來像這樣的字串 (請記住是讓輸入"H"之前的 null 字元):

blob 5Hello

為了更清楚地看到它,以下是該字串的十六進位:

62 6C 6F 62 20 35 00 48 65 6C 6C 6F

Git 然後計算 sha-1 字串:

5ab2f8a4323abafb10abb68657d9d39f1a775057

接下來,Git 會檢查現有的索引,來判斷是否該 folder\file 名稱的項目已經存在具有相同的 sha-1。因此,它會找出 blob 物件中的如果。 git\objects 資料夾,並更新其修改日期時間 (Git 會永遠不會覆寫已存在於儲存機制的 ob jects; 它會更新以新加入的物件從正在考慮進行記憶體回收的延遲時間的上次修改日期)。否則,它使用 sha-1 字串的前兩個字元的目錄名稱。 git\objects 和剩下 38 個字元,來命名之 blob 檔案再 zlib 壓縮和寫入其內容。在範例中,Git 會建立一個資料夾中的。 git\objects 呼叫 5a,然後寫入 blob 物件到該資料夾與檔案名稱 b2f8a4323abafb10abb68657d9d39f1a775057。

Git 建立 blob 物件以這種方式時,您可能會感到驚訝一個預期的檔案遺漏屬性上明顯 blob 物件: 檔案名稱 ! 這是根據設計,不過。請注意,Git 是內容可定址的檔案系統,因此,它會管理 SHA 1 命名 blob 物件,而不複製檔案。每個 blob 物件通常正由至少一個樹狀結構物件和物件樹狀結構又通常由認可物件參考。最後,Git 樹狀結構的物件來表示您暫存檔案的資料夾結構。但 Git 不會建立這些樹狀目錄物件,直到發出認可。因此,您可以推斷,如果 Git 使用只有索引準備認可物件,它也必須擷取的檔案路徑參考,在索引中每個 blob,而這就是完全有何用途。事實上,即使兩個 blob 會有 sha-1 相同的值,只要每個對應至不同的檔案名稱或不同的路徑/檔案的值,每個將會顯示為個別項目在索引中。

Git 也儲存檔案與它寫入至索引,例如檔案的每個 blob 物件的中繼資料建立和修改日期。Git 會利用這項資訊來有效率地在您使用的檔案日期比較和啟發學習法的工作目錄中偵測到檔案的變更,而非暴力重新計算的工作目錄中每個檔案的 SHA 1 值。這類您-gy 加快您在 [Team 總管變更] 窗格中看到的資訊,或當您發出瓷器 Git 狀態命令。

一旦有了索引項目及其相關聯的中繼資料的工作目錄檔案,Git 即稱為 「 追蹤 」 檔案因為它可以輕易地比較其複本的檔案會保留在工作目錄的複本。技術上來說,追蹤的檔案是指也存在於工作目錄,而且是指要包含於下次認可。這是相較於未被追蹤的檔案,其中有兩種類型: 工作目錄中,但不在索引的檔案和檔案明確指定為未要追蹤 (請參閱索引延伸模組 > 一節)。若要總括而言,索引可讓 Git 來判斷哪些檔案會受到追蹤,這並不會追蹤,這應該不會追蹤。

若要進一步了解特定索引的內容,讓我們藉由使用新的 Visual Studio 專案啟動使用具體的範例。這個專案的複雜性不是很重要: 您只需要幾個檔案,以充分說明如何運作。建立新的主控台應用程式呼叫 MSDNConsoleApp,並核取為方案及建立新 Git 存放庫核取方塊,建立目錄。按一下 [確定] 以建立方案。

因此如果您想要它們在系統上執行,請開啟命令提示字元 win d 的工作目錄和保留為您得以實現該視窗跟著做,我將在不久後,發出一些 Git 命令。若要快速開啟特定的 Git 儲存機制的 Git 命令視窗的一個方法是存取 [Visual Studio Team] 功能表,然後選取 [管理連接。您會看到一份本機 Git 儲存機制,以及至該儲存機制的工作目錄路徑。儲存機制名稱上按一下滑鼠右鍵,然後選取開啟命令提示字元,以啟動的視窗,您可以輸入 Git CLI 命令。

一旦您建立方案,開啟 [Team Explorer 分支] 窗格 (圖 4,標記 1) 若要查看建立預設分支 Git 稱為主要 (標記 2)。以滑鼠右鍵按一下 「 主要 」 分支 (標記 2) 並選取 [檢視歷程記錄 (標記 3) 至兩個認可代替您建立 Visual Studio 的檢視 (標記 4)。第一個已認可 」 訊息 「 新增到.gitignore 和.gitattributes。 」第二個已認可訊息 「 新增專案檔案 」。

檢視歷程記錄

圖 4檢視歷程記錄,以查看哪些 Visual Studio 會執行時建立新的專案

開啟 Team Explorer 變更窗格。Visual Studio 依賴 Git API 來填入這個視窗中的項目--它是 Git 狀態命令的 Visual Studio 版本。目前,此視窗會指出工作目錄中沒有取消暫存的變更。Git 會判斷的方式是比較每個索引項目,與每個工作目錄的檔案。使用索引的檔案項目和相關聯的檔案中繼資料,Git 會有需判斷您所做任何變更、 新增、 刪除,或如果您重新命名 (不含任何檔案到.gitignore 檔案中所述) 的工作目錄中的任何檔案的所有資訊。

因此索引扮演重要的角色進行 Git 智慧有關您的工作目錄樹狀結構與標頭所指向之認可物件之間的差異。若要深入了解更相關的資訊類型索引提供 Git 引擎,請移至您先前開啟的命令列視窗並發出資料夾 lowing 配管命令:

git ls-files --stage

您可以隨時目前在索引中產生檔案的完整清單,發出此命令。我在系統上,這會產生下列輸出:

100644 1ff0c423042b46cb1d617b81efb715defbe8054d 0       .gitattributes
100644 3c4efe206bd0e7230ad0ae8396a3c883c8207906 0       .gitignore
100644 f18cc2fac0bc0e4aa9c5e8655ed63fa33563ab1d 0       MSDNConsoleApp.sln
100644 88fa4027bda397de6bf19f0940e5dd6026c877f9 0       MSDNConsoleApp/App.config
100644 d837dc8996b727d6f6d2c4e788dc9857b840148a 0       MSDNConsoleApp/MSDNConsoleApp.csproj
100644 27e0d58c613432852eab6b9e693d67e5c6d7aba7 0       MSDNConsoleApp/Program.cs
100644 785cfad3244d5e16842f4cf8313c8a75e64adc38 0       MSDNConsoleApp/Properties/AssemblyInfo.cs

輸出的第一個資料行是 Unix 作業系統檔案模式中的,以八進位。Git 但不支援完整的檔案模式值。您可能只看到 100644 (適用於非 EXE 檔案) 和 100755 (適用於以 Unix 為基礎的 EXE 檔案-適用於 Win dows Git 也會使用可執行檔類型 100644)。檔案的 sha-1 值為第二個資料行。第三個資料行代表檔案--0 代表不發生衝突或 1、 2 或 3 時存在合併衝突的合併階段值。最後,請注意,每個七個 blob 物件的路徑和檔案名稱會儲存在索引中。建置晚於下次認可 (稍後將詳細) 的樹狀結構物件時,Git 會使用路徑的值。

現在,讓我們來檢查索引檔案本身。因為它是二進位檔案時,我要使用 HexEdit 4 (免費軟體十六進位編輯器位於 hexedit.com),以檢視其內容 (圖 5顯示摘錄)。

專案的 Git 索引檔十六進位傾印

圖 5: 專案的 Git 索引檔的十六進位傾印

圖 6-Git 索引標頭資料格式

索引檔案-標頭項目
00 - 03
(4 個位元組)
DIRC 目錄快取項目固定標頭。
索引的所有檔案都開頭為此項目。
04 - 07
(4 個位元組)
版本 索引版本號碼 (Git for Windows
目前使用第 2 版)。
08 - 11
(4 個位元組)
項目數目 為 4 位元組值,最多可支援索引
4,294,967,296 項目 !

索引的第一個的 12 個位元組包含標頭 (請參閱圖 6)。第一個 4 位元組永遠包含字元 DIRC (短的目錄快取)--這是一個 Git 索引通常稱為快取的原因。接下來 4 個位元組包含索引的版本號碼,除非您使用 Git 的特定功能 (例如疏鬆的簽出),預設值為 2,在這種情況下可能會將它設版本 3 或 4。最後 4 個位元組包含數量的檔案項目包含在索引中進一步向下。

遵循的 12 位元組標頭是一份 n 索引項目,其中 n 必須符合索引標頭所描述的項目數目。每個索引項目的格式如圖 7 所示。Git 排序的遞增順序依據路徑/檔案的 [名稱] 欄位的索引項目。

圖 7: Git 索引檔索引項目資料格式

索引檔案-索引項目
4 個位元組 32 位元建立時間 (秒) 自 1970 年 1 月 1 日 00:00:00 的秒數。
4 個位元組 32 位元建立的時間奈秒元件 奈秒元件的建立時間,以秒為單位的值。
4 個位元組 32 位元的修改的時間 (秒) 自 1970 年 1 月 1 日 00:00:00 的秒數。
4 個位元組 32 位元修改的時間奈秒元件 奈秒元件的建立時間,以秒為單位的值。
4 個位元組 裝置 檔案--與相關聯的中繼資料,這些是來自 Unix 作業系統上使用的檔案屬性。
4 個位元組 inode
4 個位元組 模式
4 個位元組 使用者識別碼
4 個位元組 群組識別碼
4 個位元組 檔案內容長度 檔案中內容的位元組數。
20 個位元組 SHA-1 對應 blob 物件的 SHA 1 值。
2 個位元組 旗標 (高到低位元) 1 位元: 假設-有效/假設-未變更旗標位元 1: 擴充旗標 (必須是 0 版本小於 3; 如果 1 然後是額外的 2 個位元組依照路徑 \ 檔案名稱前面) 2 位元: 合併階段 12 位元: 路徑 \ 檔案名稱的長度 (如果少於 0xFFF)
2 個位元組
(第 3 版
或更新版本)
旗標 (從高到低的位元)
1 位元: 未來使用
1 位元: 略過 worktree 旗標 (疏鬆簽出)
1 位元: 意圖加入旗標 (git 新增-N)
13 位元: 未使用,必須為零
可變長度 路徑/檔案名稱 NUL 終止

前 8 個位元組代表檔案建立為從 1970 年 1 月 1 日的午夜開始的位移的時間。第二個 8 個位元組表示檔案已修改為從 1970 年 1 月 1 日的午夜開始的位移的時間。接下來的五個 4 位元組值 (裝置、 inode、 模式、 使用者識別碼和群組識別碼) 與主機作業系統相關的檔案屬性中繼資料。用於 Windows 的唯一值是的模式中,多數通常是之前所述時顯示輸出 ls 檔案 com 強制八進位 100644 (這會將轉換為 4 位元組 814AH 的值,您可以看到在位置中的 26 H圖 5)。

下列中繼資料是檔案內容的 4 位元組長度。在圖 5,這個值開始 030,其中顯示 00 00 0A 15 (2,581 十進位)-我的系統上.gitattributes 檔案的長度:

05/08/2017  09:24 PM    <DIR>          .
05/08/2017  09:24 PM    <DIR>          ..
05/08/2017  09:24 PM             2,581 .gitattributes
05/08/2017  09:24 PM             4,565 .gitignore
05/08/2017  09:24 PM    <DIR>          MSDNConsoleApp
05/08/2017  09:24 PM             1,009 MSDNConsoleApp.sln
               3 File(s)          8,155 bytes

               3 Dir(s)  92,069,982,208 bytes free

在位移 034 H blob 物件的 20 位元組 sha-1 值:

1ff0c423042b46cb1d617b81efb715defbe8054d.

請記住,這個 sha-1 指向 blob 物件包含的檔案有問題的檔案內容:.gitattributes。

048 H 是包含兩個 1 位元旗標的 2 位元組值、 的 2 位元合併階段值,以及目前索引項目的路徑/檔案名稱的長度為 12 位元。兩個 1 位元旗標,高序位位元會指定是否索引項目的為-sume-未變更旗標設定為無效 (通常完成使用 Git 更新索引配管命令)。低序位位元表示是否其他兩個位元組的資料前面的路徑 \ 檔案名稱的項目--此位元可以是僅適用於索引版本 3 和高 1-e)。接下來的 2 位元會保存合併階段介於 0 到 3,如先前所述。12 位元值包含路徑 \ 檔案名稱字串的長度。

如果設定了擴充的旗標,2 位元組的值會保存略過 worktree 和新增意圖位元旗標,以及填滿預留位置。

最後,可變長度位元組序列的包含路徑 \ 檔案名稱。這個值以一或多個 NUL 字元終止。遵循該終止為索引中的下一個 blob 物件或一或多個索引延伸模組項目 (您會看到)。

稍早所述 Git 無法建置樹狀目錄物件,直到您認可什麼暫存。這表示是在 dex 開始只有路徑/檔案名稱和 blob 物件的參考。一旦您發出認可,不過,Git 會更新索引使其包含它的最後一個認可過程中建立樹狀目錄物件的參考。如果這些目錄參考仍然存在於您的工作目錄的 [下一步的認可,快取的樹狀結構的物件參考可用來減少 Git 必須執行的下一個認可的工作。如您所見,索引的角色是多重 facet,而這是為什麼稱為索引、 臨時區域,並快取。

索引項目所示圖 7支援只有 blob 物件參考。若要儲存的物件樹狀結構,Git 會使用擴充功能。

索引的擴充功能

索引可以包含儲存特製化的資料流來提供其他資訊,請考慮將它會監視檔案中的工作目錄,並準備下次認可時 Git 引擎的延伸模組項目。快取樹狀 ob jects 上次認可期間建立,Git 會將樹狀目錄中的擴充物件加入至工作目錄的根目錄以及與每個子目錄的索引。

圖 5標記 2、 顯示索引的最後一個位元組,並擷取儲存在索引樹狀目錄物件。圖 8顯示的樹狀目錄延伸資料的格式。

圖 8 Git 索引檔樹狀目錄延伸模組物件資料格式

索引檔案-快取的樹狀目錄延伸模組標頭
4 個位元組 樹狀結構 快取的樹狀目錄延伸模組項目固定簽章。
4 個位元組 32 位元數字代表樹狀目錄中的延伸資料的長度  

 

快取的樹狀目錄延伸模組項目
變數 Path NUL 終止的路徑字串 (空值只會針對根樹狀目錄)。
ASCII 數字 項目數目 代表此樹狀結構項目所涵蓋的索引中的項目數 ASCII 數字。
1 個位元組 20 H (空格字元)  
ASCII 數字 子樹的數目 代表此樹狀結構有子樹的數字的 ASCII 數字。
1 個位元組 0AH (換行字元)  
20 個位元組 樹狀目錄物件的 SHA 1 樹狀結構的 sha-1 值物件這
產生的項目。

樹狀目錄延伸模組資料標頭,它會顯示在位移 284 H,所組成的字串 「 樹 」 (標示樹狀目錄中快取擴充功能資料的開始) 後面接著 32 位元值,指出所示的延伸資料的長度。接下來的每個樹狀結構項目項目:第一個項目是樹狀結構路徑 (或只是 NUL 的根樹狀目錄) 的可變長度 null 結束的字串值。下列的值是 ASCII 值,所以會讀取成"7"您看到在十六進位 edi-tor-目前的樹狀結構所涵蓋的 blob 項目數目 (這是根樹狀結構,因為它有相同數目的 en 次嘗試時發出 Git ls 檔階段命令之前看到)。下一個字元是一個空格,後面接著另一個 ASCII 數字,代表目前的樹狀結構所擁有的子樹的數目。

受測專案的根樹狀結構有只有 1 的樹狀子目錄:MSDNConsoleApp。這個值後面換行字元,然後 sha-1 樹狀目錄。Sha-1 開頭位移 291,開頭為 0d21e2。

讓我們確認該 0d21e2 實際根樹狀目錄 sha-1。若要這樣做,請移至命令視窗並輸入:

git log

這會顯示最近認可的詳細資料:

commit 5192391e9f907eeb47aa38d1c6a3a4ea78e33564
Author: Jonathan Waldman <jonathan.waldman@live.com>
Date:   Mon May 8 21:24:15 2017 -0500

  Add project files.

commit dc0d3343fa24e912f08bc18aaa6f664a4a020079
Author: Jonathan Waldman <jonathan.waldman@live.com>
Date:   Mon May 8 21:24:07 2017 -0500

  Add .gitignore and .gitattributes.

最新認可就是一個包含時間戳記 21:24:15,因此是指上次更新索引。我可以使用該認可 sha-1 來尋找根樹狀結構 sha-1 值:

git cat-file -p 51923

這會產生下列輸出:

tree 0d21e2f7f760f77ead2cb85cc128efb13f56401d
parent dc0d3343fa24e912f08bc18aaa6f664a4a020079
author Jonathan Waldman <jonathan.waldman@live.com> 1494296655 -0500
committer Jonathan Waldman <jonathan.waldman@live.com> 1494296655 -0500

前述的樹狀結構項目是根樹狀目錄物件。它可確認位移 0d21e2 值在索引傾印 291 H,事實上,對於根樹狀目錄物件的 sha-1。

其他的樹狀結構項目緊接 sha-1 值,2A5H 位移處開始。若要確認 sha-1 之物件的值快取的樹狀結構的根樹狀結構下方,執行下列命令:

git ls-tree -r -d master

這會顯示只有樹狀目錄中的物件,遞迴地在最新分支上:

040000 tree c7c367f2d5688dddc25e59525cc6b8efd0df914d    MSDNConsoleApp
040000 tree 2723ceb04eda3051abf913782fadeebc97e0123c    MSDNConsoleApp/Properties

040000 第一個資料行中的模式值會指出這個物件是目錄,而不是檔案。

最後,索引的最後 20 個位元組包含代表索引本身的 sha-1 雜湊:如預期般,Git 會使用這個 sha-1 值來驗證索引的資料完整性。

雖然我們已討論所有的這篇文章範例索引檔案中的項目,較大且更複雜的索引檔案會有範數。索引的檔案格式支援其他擴充功能資料流,例如:

  • 其中一個支援合併作業並解決合併衝突。其簽章 」 REUC 」 (適用於解析復原衝突)。
  • 其中一個來維護快取的未被追蹤的檔案 (這些是要排除在追蹤、.gitignore 和.git\info\exclude 檔案中,以及 core.excludesfile 所指向的檔案之指定的檔案)。簽章 」 UNTR。 」
  • 另一種支援以加速索引的分割索引模式更新非常大的索引檔案。簽章 「 連結 」。

索引的擴充功能讓您可以繼續加入至其功能。

總結

在本文中,我檢閱 Git 三樹狀架構,而探討後方及其索引檔的詳細資料。我會顯示 Git 更新的特定作業的回應中的索引,才能執行其他作業,它也依賴資訊索引包含。

您可使用 Git,而不考慮太多索引。但索引的相關知識,可提供 invalua b 深入了解 Git 的核心功能脫落 light Git 偵測工作目錄中的檔案變更的方式、 暫存區域的是和用處 Git 如何管理合併,以及為什麼 Git 執行某些作業時,快速抵禦致命。它也可輕鬆地了解簽出和重訂基底命令-和彈性、 混合和硬重設之間的差異 ence 命令列的變化。這類功能可讓您指定是否索引、 工作目錄,或兩者的索引和工作目錄應該更新時發出的特定命令。了解 Git 工作流程時,您會看到這類選項策略和進階的作業。本文的目的是引導您了索引播放,讓您可以進一步摘要式中運用方式的 im portant 角色。


Jonathan Waldman是 Microsoft 認證的人員誰曾與 Microsoft 技術自其開始和人員在軟體 ergonomics 特製化。Waldman Pluralsight 技術團隊的成員,而且他目前領導機構和私用磁區軟體開發專案。他可以在達到jonathan.waldman@live.com

非常感謝下列 Microsoft 技術專家檢閱這篇文章:Kraig Brockschmidt、 Saeed Noursalehi、 Ralph Squillace 和 Edward Sgs-thomson


MSDN Magazine 論壇中的這篇文章的討論