在閱讀本手冊時，擁有一個 Git 倉庫進行實驗將非常有用。

獲取倉庫的最佳方式是使用 git-clone[1] 命令下載現有倉庫的副本。如果您還沒有想到專案，這裡有一些有趣的例子

對於大型專案，初始克隆可能很耗時，但您只需克隆一次。

克隆命令會建立一個以專案命名的目錄（在上面的示例中為 git 或 linux）。cd 進入此目錄後，您會發現它包含專案檔案的副本，稱為工作樹，以及一個名為 .git 的特殊頂級目錄，其中包含專案的所有歷史資訊。

Git 最適合被視為儲存檔案集合歷史記錄的工具。它將歷史記錄儲存為專案內容的相互關聯的壓縮快照集合。在 Git 中，每個這樣的版本都稱為提交。

這些快照不一定都從舊到新排列成一行；相反，工作可能會同時沿著平行的開發線進行，這些開發線稱為分支，它們可以合併和分化。

一個 Git 倉庫可以跟蹤多個分支上的開發。它透過維護一個頭列表來實現這一點，這些頭引用了每個分支上的最新提交；git-branch[1] 命令顯示分支頭的列表

新克隆的倉庫預設包含一個名為“master”的單個分支頭，工作目錄初始化為該分支頭所引用的專案狀態。

大多數專案也使用標籤。標籤和頭一樣，是對專案歷史的引用，可以使用 git-tag[1] 命令列出

標籤預期始終指向專案的相同版本，而頭則預期隨著開發進展而前進。

建立一個指向其中一個版本的新分支頭，並使用 git-switch[1] 檢出它

然後工作目錄會反映專案在被標記為 v2.6.13 時的內容，並且 git-branch[1] 顯示兩個分支，星號標記當前已檢出的分支

如果您決定想檢視版本 2.6.17，您可以修改當前分支以指向 v2.6.17，使用

請注意，如果當前分支頭是您對歷史上特定點的唯一引用，那麼重置該分支可能會導致您無法找到它曾經指向的歷史記錄；因此請謹慎使用此命令。

專案歷史中的每個更改都由一個提交表示。git-show[1] 命令顯示當前分支上的最新提交

如您所見，一次提交顯示了誰進行了最新更改、他們做了什麼以及原因。

每個提交都有一個 40 位的十六進位制 ID，有時稱為“物件名稱”或“SHA-1 ID”，顯示在 git show 輸出的第一行。您通常可以使用更短的名稱（例如標籤或分支名稱）來引用提交，但這個更長的名稱也很有用。最重要的是，它是此提交的全域性唯一名稱：因此如果您告訴其他人物件名稱（例如在電子郵件中），則可以保證該名稱將引用其倉庫中與您倉庫中相同的提交（假設他們的倉庫根本有該提交）。由於物件名稱是根據提交內容計算的雜湊值，因此可以保證提交永遠不會在名稱不變的情況下發生更改。

事實上，在 Git 概念 中我們將看到，Git 歷史中儲存的所有內容，包括檔案資料和目錄內容，都儲存在一個物件中，該物件的名稱是其內容的雜湊值。

建立、刪除和修改分支既快速又簡單；以下是命令摘要

特殊符號“HEAD”始終可用於引用當前分支。事實上，Git 在 .git 目錄中使用一個名為 HEAD 的檔案來記住哪個分支是當前分支

git switch 命令通常需要一個分支頭，但當使用 --detach 呼叫時，它也會接受任意提交；例如，您可以檢出由標籤引用的提交

HEAD 隨後引用提交的 SHA-1 而不是分支，並且 git branch 顯示您不再位於任何分支上

在這種情況下，我們說 HEAD 是“分離的”。

這是檢出特定版本的簡單方法，而無需為新分支命名。如果您決定這樣做，稍後仍然可以為這個版本建立一個新分支（或標籤）。

您克隆時建立的“master”分支是您克隆來源倉庫中 HEAD 的副本。不過，該倉庫可能還有其他分支，並且您的本地倉庫會保留跟蹤這些遠端分支的本地跟蹤分支，您可以使用 git-branch[1] 的 -r 選項檢視它們

在此示例中，“origin”被稱為遠端倉庫，或簡稱“remote”。從我們的角度來看，此倉庫的分支被稱為“遠端分支”。上面列出的遠端跟蹤分支是在克隆時根據遠端分支建立的，並將透過 git fetch（因此是 git pull）和 git push 進行更新。有關詳細資訊，請參閱 使用 git fetch 更新倉庫。

您可能希望在自己的分支上基於這些遠端跟蹤分支之一進行構建，就像您對標籤所做的那樣

您也可以直接檢出 origin/todo 以檢視或編寫一次性補丁。請參閱 分離頭。

請注意，“origin”名稱只是 Git 預設用來指代您克隆來源倉庫的名稱。

分支、遠端跟蹤分支和標籤都是對提交的引用。所有引用都以 refs 開頭的斜槓分隔路徑名命名；我們目前使用的名稱實際上是簡寫

如果例如存在同名的標籤和分支，則完整名稱偶爾會很有用。

（新建立的引用實際上儲存在 .git/refs 目錄下，位於其名稱給定的路徑下。然而，出於效率原因，它們也可以打包在一個檔案中；請參閱 git-pack-refs[1]）。

另一個有用的快捷方式是，倉庫的“HEAD”可以直接使用該倉庫的名稱來引用。因此，例如，“origin”通常是倉庫“origin”中 HEAD 分支的快捷方式。

有關 Git 檢查引用的完整路徑列表，以及當存在多個具有相同簡寫名稱的引用時它用於決定選擇哪個的順序，請參閱 gitrevisions[7] 手冊頁的“指定修訂”部分。

克隆倉庫並提交您自己的更改後，您可能希望檢查原始倉庫是否有更新。

不帶任何引數的 git-fetch 命令會將所有遠端跟蹤分支更新為原始倉庫中找到的最新版本。它不會觸及您自己的任何分支——甚至包括為您在克隆時建立的“master”分支。

您還可以使用 git-remote[1] 跟蹤您克隆來源倉庫以外的其他倉庫中的分支

新的遠端跟蹤分支將儲存在您提供給 git remote add 的簡寫名稱下，在本例中為 staging

如果您稍後執行 git fetch <remote>，則指定 <remote> 的遠端跟蹤分支將被更新。

如果您檢視檔案 .git/config，您會發現 Git 添加了一個新的節

這就是 Git 跟蹤遠端分支的原因；您可以透過使用文字編輯器編輯 .git/config 來修改或刪除這些配置選項。（有關詳細資訊，請參閱 git-config[1] 的“配置檔案”部分。）

假設您的專案版本 2.6.18 正常工作，但“master”上的版本崩潰了。有時，找到這種迴歸原因的最佳方法是在專案歷史中執行暴力搜尋，以找到導致問題的特定提交。git-bisect[1] 命令可以幫助您完成此操作

此時如果您執行 git branch，您會看到 Git 暫時將您移動到了“（無分支）”狀態。HEAD 現在已從任何分支分離，並直接指向一個提交（提交 ID 為 65934），該提交可從“master”到達但無法從 v2.6.18 到達。編譯並測試它，看看是否會崩潰。假設它確實崩潰了。然後

檢出舊版本。像這樣繼續，在每個階段告訴 Git 它給您的版本是好的還是壞的，並注意每次剩餘要測試的修訂版數量大約減少一半。

大約 13 次測試（在本例中）後，它將輸出導致問題的提交的提交 ID。然後您可以使用 git-show[1] 檢查該提交，找出是誰編寫的，並附上提交 ID 給他們傳送錯誤報告。最後，執行

將您返回到之前的分支。

請注意，git bisect 在每個點為您檢出的版本只是一個建議，如果您認為這是一個好主意，您可以自由嘗試不同的版本。例如，有時您可能會遇到一個破壞了不相關內容的提交；執行

它將執行 gitk 並用一個標記“bisect”來標記它選擇的提交。選擇一個看起來安全的附近提交，記下其提交 ID，然後使用以下命令檢出它

然後測試，根據需要執行 bisect good 或 bisect bad，然後繼續。

除了 git bisect visualize 然後 git reset --hard fb47ddb2db 之外，您可能只想告訴 Git 您想跳過當前提交

然而，在這種情況下，Git 最終可能無法區分一些最初跳過的提交和後續的壞提交中第一個壞的那個。

如果您有一個可以區分好提交和壞提交的測試指令碼，也有方法可以自動化二分查詢過程。有關此功能和其他 git bisect 功能的更多資訊，請參閱 git-bisect[1]。

我們已經看到幾種命名提交的方式

還有更多方式；有關命名修訂的完整列表，請參閱 gitrevisions[7] 手冊頁的“指定修訂”部分。一些示例

回想一下，合併提交可能有一個以上的父提交；預設情況下，^ 和 ~ 跟隨提交中列出的第一個父提交，但您也可以選擇

除了 HEAD 之外，還有其他幾個特殊的提交名稱

合併（稍後討論）以及諸如 git reset 之類的操作（它們會更改當前檢出的提交），通常會將 ORIG_HEAD 設定為當前操作之前 HEAD 的值。

git fetch 操作始終將最後獲取的分支的頭儲存在 FETCH_HEAD 中。例如，如果您執行 git fetch 而不指定本地分支作為操作目標

獲取的提交仍將可透過 FETCH_HEAD 獲取。

當我們討論合併時，我們還會看到特殊名稱 MERGE_HEAD，它指的是我們要合併到當前分支中的另一個分支。

git-rev-parse[1] 命令是一個低階命令，偶爾可用於將提交的某個名稱轉換為該提交的物件名稱

我們還可以建立一個標籤來引用某個特定提交；執行以下命令後

您可以使用 stable-1 來引用提交 1b2e1d63ff。

這會建立一個“輕量級”標籤。如果您還想在標籤中包含評論，並可能對其進行加密簽名，那麼您應該改為建立一個標籤物件；有關詳細資訊，請參閱 git-tag[1] 手冊頁。

git-log[1] 命令可以顯示提交列表。它本身顯示所有可從父提交到達的提交；但您也可以提出更具體的請求

當然，您可以將所有這些結合起來；以下命令查詢自 v2.5 以來修改過 Makefile 或 fs 下任何檔案的提交

您還可以要求 git log 顯示補丁

有關更多顯示選項，請參閱 git-log[1] 手冊頁中的 --pretty 選項。

請注意，git log 從最新提交開始，然後向後遍歷其父提交；然而，由於 Git 歷史可以包含多個獨立的開發線，因此提交的特定列出順序可能有些隨意。

您可以使用 git-diff[1] 在任意兩個版本之間生成差異

這會生成兩個分支尖端之間的差異。如果您希望找到從它們的共同祖先到測試的差異，您可以使用三個點而不是兩個點

有時您需要的是一組補丁；為此您可以使用 git-format-patch[1]

將生成一個檔案，其中包含可從 test 訪問但不能從 master 訪問的每個提交的補丁。

您總是可以透過先檢出正確的修訂版本來檢視檔案的舊版本。但有時更方便的是無需檢出任何內容即可檢視單個檔案的舊版本；此命令可實現這一點

冒號前可以是任何命名提交的內容，冒號後可以是 Git 跟蹤的檔案的任何路徑。

在建立任何提交之前，你應該向 Git 介紹你自己。最簡單的方法是使用 git-config[1]

這將在你的主目錄中名為 .gitconfig 的檔案中新增以下內容

有關配置檔案的詳細資訊，請參閱 git-config[1] 的“配置檔案”部分。該檔案是純文字檔案，因此你也可以使用你喜歡的編輯器對其進行編輯。

從頭開始建立一個新倉庫非常簡單

如果你有一些初始內容（例如，一個 tarball）

建立一個新提交需要三個步驟

在實踐中，你可以根據需要多次交替和重複步驟 1 和 2：為了跟蹤你在步驟 3 中想要提交的內容，Git 在一個名為“索引”（index）的特殊暫存區中維護了樹內容的快照。

最初，索引的內容將與 HEAD 的內容相同。因此，顯示 HEAD 和索引之間差異的命令 git diff --cached 在那時應該不會產生任何輸出。

修改索引很簡單

要使用新檔案或修改後的檔案的內容更新索引，請使用

要從索引和工作樹中刪除檔案，請使用

每一步之後，你都可以驗證

始終顯示 HEAD 和索引檔案之間的差異——這是如果你現在建立提交將提交的內容——並且

顯示工作樹和索引檔案之間的差異。

請注意，git add 總是隻將檔案的當前內容新增到索引中；對同一檔案的進一步更改將被忽略，除非你再次對該檔案執行 git add。

當你準備好時，只需執行

Git 將提示你輸入提交資訊，然後建立新提交。使用以下命令檢查以確保它符合你的預期

作為一項特殊快捷方式，

將更新索引中所有已修改或已刪除的檔案，並一步完成提交。

有許多命令對於跟蹤你即將提交的內容很有用

你還可以使用 git-gui[1] 來建立提交、檢視索引和工作樹檔案中的更改，並單獨選擇要包含在索引中的差異塊（透過右鍵單擊差異塊並選擇“Stage Hunk For Commit”）。

雖然不是必需的，但最好以一行簡短（不超過 50 個字元）的更改摘要作為提交資訊的開頭，後面跟一個空行，然後是更詳細的描述。提交資訊中直到第一個空行之前的文字被視為提交標題，該標題在整個 Git 中都會使用。例如，git-format-patch[1] 將提交轉換為電子郵件，它將標題用作主題行，其餘提交內容用作正文。

專案通常會生成你不想用 Git 跟蹤的檔案。這通常包括構建過程生成的檔案或編輯器建立的臨時備份檔案。當然，不用 Git 跟蹤檔案只是不對其呼叫 git add 的問題。但這些未跟蹤的檔案散落在各處很快就會變得令人煩惱；例如，它們使得 git add . 幾乎毫無用處，並且它們會不斷出現在 git status 的輸出中。

你可以透過在工作目錄的頂層建立一個名為 .gitignore 的檔案來告訴 Git 忽略某些檔案，其內容如下

有關語法的詳細說明，請參閱 gitignore[5]。你還可以將 .gitignore 檔案放置在工作樹中的其他目錄中，它們將應用於這些目錄及其子目錄。.gitignore 檔案可以像其他任何檔案一樣新增到你的倉庫中（只需像往常一樣執行 git add .gitignore 和 git commit），當排除模式（例如匹配構建輸出檔案的模式）對克隆你倉庫的其他使用者也有意義時，這會很方便。

如果你希望排除模式僅影響某些倉庫（而不是給定專案的每個倉庫），你可以將它們放入你的倉庫中名為 .git/info/exclude 的檔案，或由 core.excludesFile 配置變數指定的任何檔案中。某些 Git 命令也可以直接在命令列上接受排除模式。有關詳細資訊，請參閱 gitignore[5]。

你可以使用 git-merge[1] 將兩個分叉的開發分支重新合併

將分支 branchname 中的開發內容合併到當前分支中。

合併是透過合併自其歷史分叉以來 branchname 中所做的更改以及當前分支中直到最新提交所做的更改來完成的。當合並乾淨完成時，工作樹會被合併結果覆蓋；當合並導致衝突時，則會被部分合並的結果覆蓋。因此，如果你有未提交的更改涉及到與合併受影響的檔案相同的檔案，Git 將拒絕繼續。大多數情況下，你會希望在合併之前提交你的更改，如果你沒有這樣做，那麼 git-stash[1] 可以在你進行合併時將這些更改暫存起來，並在之後重新應用它們。

如果更改足夠獨立，Git 將自動完成合並並提交結果（或者在快進的情況下重用現有提交，見下文）。另一方面，如果存在衝突——例如，如果同一個檔案在遠端分支和本地分支中以兩種不同的方式被修改——那麼你將收到警告；輸出可能看起來像這樣

衝突標記會留在有問題的檔案中，手動解決衝突後，你可以用新內容更新索引並執行 Git commit，就像你通常建立新檔案時那樣。

如果你使用 gitk 檢查結果提交，你將看到它有兩個父提交，一個指向當前分支的頂部，另一個指向另一個分支的頂部。

當合並未能自動解決時，Git 會將索引和工作樹置於一種特殊狀態，為你提供解決合併所需的所有資訊。

有衝突的檔案在索引中會被特殊標記，因此在你解決問題並更新索引之前，git-commit[1] 將會失敗

此外，git-status[1] 會將這些檔案列為“未合併”，並且有衝突的檔案會新增衝突標記，如下所示

你只需編輯檔案來解決衝突，然後

請注意，提交資訊將已為你填寫了一些關於合併的資訊。通常你可以直接使用此預設資訊而無需更改，但如果需要，你可以新增自己的額外註釋。

以上就是解決簡單合併所需瞭解的全部內容。但 Git 還提供了更多資訊來幫助解決衝突

如果你陷入困境並決定放棄一切，你總是可以透過以下方式返回到合併前的狀態

或者，如果你已經提交了你想要放棄的合併，

然而，在某些情況下，最後一個命令可能很危險——如果某個你已經提交的提交本身可能已經合併到另一個分支中，則切勿丟棄它，因為這樣做可能會使後續合併混淆。

上面沒有提到一個特殊情況，它被區別對待。通常，合併會產生一個合併提交，它有兩個父提交，分別指向兩條被合併的開發線。

然而，如果當前分支是另一個分支的祖先——即當前分支中存在的每個提交都已包含在另一個分支中——那麼 Git 只會執行“快進”；當前分支的 HEAD 會向前移動，指向被合併分支的 HEAD，而不會建立任何新提交。

如果你搞砸了工作樹，但尚未提交你的錯誤，你可以使用以下命令將整個工作樹恢復到上次提交的狀態

如果你做了一個後來希望沒有做過的提交，有兩種根本不同的方法來解決問題

在大型倉庫中，Git 依賴壓縮來防止歷史資訊佔用過多的磁碟或記憶體空間。一些 Git 命令可能會自動執行 git-gc[1]，因此你無需擔心手動執行它。但是，壓縮大型倉庫可能需要一些時間，因此你可能希望顯式呼叫 gc 以避免在不方便時自動啟動壓縮。

在你克隆倉庫並提交了一些自己的更改後，你可能希望檢查原始倉庫的更新並將其合併到你自己的工作中。

我們已經瞭解了如何使遠端跟蹤分支保持最新與 git-fetch[1]，以及如何合併兩個分支。因此，你可以使用以下命令合併原始倉庫 master 分支的更改

然而，git-pull[1] 命令提供了一種一步完成此操作的方法

實際上，如果你已經檢出了 master，那麼該分支已透過 git clone 配置為從 origin 倉庫的 HEAD 分支獲取更改。因此，通常你只需簡單地執行以下操作即可完成上述任務

此命令將從遠端分支獲取更改到你的遠端跟蹤分支 origin/*，並將預設分支合併到當前分支。

更一般地說，從遠端跟蹤分支建立的分支將預設從該分支拉取。有關如何控制這些預設值的詳細資訊，請參閱 branch.<name>.remote 和 branch.<name>.merge 選項在 git-config[1] 中的描述，以及 git-checkout[1] 中 --track 選項的討論。

除了節省你的按鍵次數外，git pull 還會透過生成一個預設的提交資訊來幫助你，其中記錄了你從中拉取的分支和倉庫。

（但請注意，在快進的情況下不會建立此類提交；相反，你的分支將僅更新以指向來自上游分支的最新提交。）

git pull 命令也可以將 . 作為“遠端”倉庫，在這種情況下它只會合併當前倉庫中的一個分支；所以命令

大致等價。

如果你只有少量更改，最簡單的提交方式可能就是透過電子郵件傳送補丁

首先，使用 git-format-patch[1]；例如

將在當前目錄中生成一系列編號檔案，當前分支中的每個補丁一個檔案，但 origin/HEAD 中的除外。

git format-patch 可以包含一個初始的“封面信”。你可以在 format-patch 在提交資訊之後但在補丁本身之前放置的三條虛線之後插入對單個補丁的評論。如果你使用 git notes 來跟蹤你的封面信材料，git format-patch --notes 將以類似的方式包含提交的註釋。

然後你可以將這些匯入到你的郵件客戶端並手動傳送。但是，如果你有大量要一次性發送，你可能更喜歡使用 git-send-email[1] 指令碼來自動化該過程。請先諮詢你專案的郵件列表，以確定他們提交補丁的要求。

Git 還提供了一個名為 git-am[1]（am 代表“apply mailbox”）的工具，用於匯入此類透過電子郵件傳送的系列補丁。只需將所有包含補丁的訊息按順序儲存到一個郵箱檔案，例如 patches.mbox，然後執行

Git 將按順序應用每個補丁；如果發現任何衝突，它將停止，你可以按照“解決合併”中描述的方式修復衝突。（-3 選項告訴 Git 執行合併；如果你希望它只中止並保持你的樹和索引不變，你可以省略該選項。）

一旦索引使用衝突解決的結果進行了更新，只需執行，而無需建立新提交

Git 將為你建立提交併繼續從郵箱中應用剩餘的補丁。

最終結果將是一系列提交，原始郵箱中的每個補丁對應一個，其作者和提交日誌資訊均取自包含相應補丁的訊息。

向專案提交更改的另一種方法是告訴該專案的維護者使用 git-pull[1] 從你的倉庫拉取更改。在“使用 git pull 獲取更新”一節中，我們將其描述為從“主”倉庫獲取更新的方法，但它反向也同樣適用。

如果你和維護者都在同一臺機器上擁有賬戶，那麼你可以直接從彼此的倉庫中拉取更改；接受倉庫 URL 作為引數的命令也將接受本地目錄名

或 SSH URL

對於開發人員較少的專案，或者用於同步少數私有倉庫，這可能就是你所需要的全部。

然而，更常見的方法是維護一個單獨的公共倉庫（通常在不同的主機上），供其他人從中拉取更改。這通常更方便，並且允許你將私有進行中的工作與公開可見的工作清楚地分離。

你將繼續在你的個人倉庫中進行日常工作，但會定期將更改從你的個人倉庫“推”送到你的公共倉庫中，允許其他開發人員從該倉庫拉取。因此，在有另一個開發人員擁有公共倉庫的情況下，更改的流程如下所示

我們將在以下章節中解釋如何進行此操作。

一個具有截斷歷史的 淺克隆（shallow clone），在只對專案近期歷史感興趣且從上游獲取完整歷史成本很高時非常有用。

透過指定 git-clone[1] 的 --depth 開關來建立 淺克隆。深度稍後可以使用 git-fetch[1] 的 --depth 開關進行更改，或者使用 --unshallow 恢復完整歷史。

在 淺克隆 中進行合併是可行的，只要合併基礎（merge base）在近期歷史中。否則，這將類似於合併不相關的歷史，並可能導致巨大的衝突。這個限制可能會使這種倉庫不適合用於基於合併的工作流。

假設你是一個大型專案的貢獻者，並且你想新增一個複雜的功能，並以一種讓其他開發者容易閱讀你的更改、驗證其正確性並理解你為什麼進行每項更改的方式來呈現它。

如果你將所有更改作為單個補丁（或提交）呈現，他們可能會發現一次消化太多。

如果你向他們展示你工作的完整歷史，包括錯誤、更正和死衚衕，他們可能會不知所措。

因此，理想情況通常是生成一系列補丁，使得

我們將介紹一些可以幫助你完成此操作的工具，解釋如何使用它們，然後解釋由於你正在重寫歷史可能出現的一些問題。

假設你在遠端跟蹤分支 origin 上建立了一個分支 mywork，並在其之上建立了一些提交

你尚未將任何內容合併到 mywork 中，因此它只是在 origin 之上的一系列簡單線性補丁

上游專案已經完成了一些更有趣的工作，並且 origin 已經向前推進

此時，你可以使用 pull 將你的更改合併回來；結果將建立一個新的合併提交，像這樣

然而，如果你更喜歡將 mywork 中的歷史保持為簡單的提交系列而不包含任何合併，你可以選擇使用 git-rebase[1]

這將從 mywork 中移除你的每個提交，暫時將它們儲存為補丁（在一個名為 .git/rebase-apply 的目錄中），更新 mywork 以指向 origin 的最新版本，然後將每個已儲存的補丁應用到新的 mywork。結果將如下所示

在此過程中，它可能會發現衝突。在這種情況下，它會停止並允許你解決衝突；解決衝突後，使用 git add 更新索引內容，然後，不要執行 git commit，只需執行

Git 將繼續應用其餘的補丁。

在任何時候，你都可以使用 --abort 選項來中止此過程並將 mywork 恢復到你開始變基之前的狀態

如果你需要在分支中重新排序或編輯多個提交，使用 git rebase -i 可能會更容易，它允許你在變基期間重新排序和壓縮提交，以及標記它們進行單獨編輯。有關詳細資訊，請參閱 使用互動式變基，有關替代方案，請參閱 重新排序或從補丁系列中選擇。

我們在 透過重寫歷史來修復錯誤 中看到，你可以使用以下命令替換最近的提交

這會將舊提交替換為包含你的更改的新提交，讓你有機會首先編輯舊的提交訊息。這對於修復你上次提交中的拼寫錯誤，或調整暫存不佳的提交的補丁內容非常有用。

如果你需要修改歷史中更深層的提交，可以使用 互動式變基的 edit 指令。

有時你想編輯歷史中更深層的提交。一種方法是使用 git format-patch 建立一系列補丁，然後將狀態重置到補丁之前

然後根據需要修改、重新排序或刪除補丁，然後再使用 git-am[1] 再次應用它們

你也可以使用互動式變基來編輯補丁系列。這與 使用 format-patch 重新排序補丁系列 相同，因此請使用你最喜歡的介面。

將你當前的 HEAD 變基到你想要原樣保留的最後一個提交上。例如，如果你想重新排序最後 5 個提交，請使用

這將在你的編輯器中開啟一個列表，其中包含執行變基所需的步驟。

如註釋中所述，你可以透過編輯列表來重新排序提交、將它們壓縮在一起、編輯提交訊息等。一旦你滿意，儲存列表並關閉編輯器，變基將開始。

當 pick 被替換為 edit，或者列表中的某個步驟無法自動解決衝突並需要你幫助時，變基將停止。當你完成編輯和/或解決衝突後，你可以使用 git rebase --continue 繼續。如果你覺得情況變得過於複雜，你始終可以使用 git rebase --abort 退出。即使變基完成後，你仍然可以透過使用 reflog 恢復原始分支。

有關此過程和更多技巧的詳細討論，請參閱 git-rebase[1] 的“互動模式”部分。

還有許多其他工具，例如 StGit，它們旨在維護補丁系列。這些超出了本手冊的範圍。

重寫分支歷史的主要問題與合併有關。假設有人拉取了你的分支並將其合併到他們的分支中，結果大致如下

然後假設你修改了最後三個提交

如果我們在一個倉庫中一起檢查所有這些歷史，它將看起來像

Git 無法知道新頭是舊頭的更新版本；它對待這種情況的方式與兩個開發者並行獨立地對舊頭和新頭進行工作時完全相同。此時，如果有人試圖將新頭合併到他們的分支中，Git 將嘗試將兩條（舊的和新的）開發線合併在一起，而不是嘗試用新的替換舊的。結果很可能出乎意料。

你仍然可以選擇釋出其歷史被重寫的分支，並且其他人能夠拉取這些分支以檢查或測試它們可能很有用，但他們不應嘗試將此類分支拉入他們自己的工作中。

對於支援正確合併的真正分散式開發，已釋出的分支絕不應該被重寫。

git-bisect[1] 命令可以正確處理包含合併提交的歷史。然而，當它找到的提交是合併提交時，使用者可能需要比平時更努力地找出為什麼該提交引入了問題。

想象一下這段歷史

假設在上方開發線中，存在於 Z 的某個函式的含義在提交 X 處發生了改變。從 Z 到 A 的提交改變了函式的實現和所有存在於 Z 的呼叫點，以及它們新增的新呼叫點，以保持一致。在 A 處沒有錯誤。

同時，假設在下方開發線中，某人在提交 Y 處為該函式添加了一個新的呼叫點。從 Z 到 B 的提交都假定該函式的舊語義，並且呼叫者和被呼叫者彼此一致。在 B 處也沒有錯誤。

進一步假設兩條開發線在 C 處乾淨地合併，因此不需要解決衝突。

然而，C 處的程式碼是損壞的，因為在下方開發線上新增的呼叫者尚未轉換為上方開發線上引入的新語義。因此，如果你只知道 D 是壞的，Z 是好的，並且 git-bisect[1] 將 C 標識為罪魁禍首，你將如何找出問題是由於語義的這種改變？

當 git bisect 的結果是一個非合併提交時，你通常應該能夠透過只檢查該提交來發現問題。開發者可以透過將他們的更改分解為小的獨立提交來簡化此過程。然而，在上述情況下這無濟於事，因為問題從任何單個提交的檢查中都不明顯；相反，需要對開發有一個全域性的檢視。更糟糕的是，有問題的函式中的語義更改可能只是上方開發線中更改的一小部分。

另一方面，如果在 C 處不是合併，而是將 Z 到 B 之間的歷史變基到 A 的頂部，你將得到這個線性歷史

在 Z 和 D* 之間進行二分查詢將命中單個罪魁禍首提交 Y*，並且理解 Y* 為什麼損壞可能會更容易。

部分出於這個原因，許多經驗豐富的 Git 使用者，即使在進行一個大量使用合併的專案時，也會在釋出前透過對最新上游版本進行變基來保持歷史的線性。

除了使用 git-remote[1]，你還可以選擇一次只更新一個分支，並將其儲存在本地的任意名稱下

第一個引數 origin 只是告訴 Git 從你最初克隆的倉庫中抓取。第二個引數告訴 Git 從遠端倉庫抓取名為 todo 的分支，並將其儲存在本地名為 refs/heads/my-todo-work 的位置。

你也可以從其他倉庫抓取分支；因此

將建立一個名為 example-master 的新分支，並在其中儲存來自給定 URL 倉庫中名為 master 的分支。如果你已經有一個名為 example-master 的分支，它將嘗試 快進 到 example.com 的 master 分支所指定的提交。更詳細地說

在前面的示例中，當更新現有分支時，git fetch 會檢查以確保遠端分支上的最新提交是你本地分支副本上最新提交的後代，然後才將你的本地分支副本更新為指向新提交。Git 將此過程稱為 快進。

快進看起來像這樣

在某些情況下，新頭可能實際上不是舊頭的後代。例如，開發者可能意識到犯了一個嚴重錯誤並決定回溯，導致出現以下情況

在這種情況下，git fetch 將失敗，並打印出警告。

在這種情況下，你仍然可以強制 Git 更新到新頭，如下一節所述。然而，請注意，在上述情況下，這可能意味著丟失標記為 a 和 b 的提交，除非你已經建立了指向它們的自己的引用。

如果 git fetch 失敗，因為分支的新頭不是舊頭的後代，你可以使用以下命令強制更新

請注意 + 符號的新增。或者，你可以使用 -f 標誌來強制更新所有抓取的分支，如下所示

請注意，舊版本 example/master 指向的提交可能會丟失，正如我們在上一節中看到的。

我們上面看到，origin 只是一個快捷方式，用於指代你最初克隆的倉庫。此資訊儲存在 Git 配置變數中，你可以使用 git-config[1] 檢視

如果你還有其他經常使用的倉庫，可以建立類似的配置選項以節省輸入；例如，

將以下內容新增到 .git/config

另請注意，上述配置可以透過直接編輯檔案 .git/config 而不是使用 git-remote[1] 來執行。

配置遠端後，以下三個命令將執行相同的操作

有關上述配置選項的更多詳細資訊，請參閱 git-config[1]；有關 refspec 語法的更多詳細資訊，請參閱 git-fetch[1]。

我們已經在 理解歷史：提交 中看到，所有提交都儲存在一個 40 位的“物件名稱”下。實際上，表示專案歷史所需的所有資訊都儲存在具有此類名稱的物件中。在每種情況下，名稱都是透過對物件內容進行 SHA-1 雜湊計算得出的。SHA-1 雜湊是一種加密雜湊函式。這對我們來說意味著不可能找到兩個具有相同名稱的不同物件。這有許多優點，其中包括

(有關物件格式和 SHA-1 計算的詳細資訊，請參閱 物件儲存格式。)

有四種不同型別的物件：“blob”、“tree”、“commit”和“tag”。

物件型別的一些更詳細資訊

索引是一個二進位制檔案（通常儲存在 .git/index 中），包含一個已排序的路徑名列表，每個路徑名都帶有許可權和一個 blob 物件的 SHA-1；git-ls-files[1] 可以顯示索引的內容：

請注意，在舊的文件中，你可能會看到索引被稱為“當前目錄快取”或簡稱“快取”。它有三個重要的特性：

因此，索引是一種臨時暫存區，其中填充了你正在處理的樹。

如果你完全清除索引，只要你擁有它所描述的樹的名稱，你通常就不會丟失任何資訊。

在釋出引用子模組的超級專案的更改之前，請務必先發布子模組的更改。如果你忘記釋出子模組的更改，其他人將無法克隆倉庫：

在較舊的 Git 版本中，很容易忘記在子模組中提交新增或修改的檔案，這會悄無聲息地導致與不推送子模組更改類似的問題。從 Git 1.7.0 開始，超級專案中的 git status 和 git diff 都會在子模組包含新增或修改檔案時將其顯示為已修改，以防止意外提交這種狀態。git diff 在生成補丁輸出或與 --submodule 選項一起使用時，也會在工作樹一側新增 -dirty：

你也不應該將子模組中的分支回溯到超出任何超級專案曾經記錄過的提交之外。

如果在未檢出分支的情況下在子模組中進行並提交了更改，那麼執行 git submodule update 是不安全的。它們將被靜默覆蓋：

如果你的子模組工作樹中有未提交的更改，git submodule update 將不會覆蓋它們。相反，你會收到通常的關於無法從髒分支切換的警告。

git-cat-file[1] 命令可以顯示任何物件的內容，儘管高階的 git-show[1] 通常更有用。

git-commit-tree[1] 命令允許構建具有任意父級和樹的提交。

可以使用 git-write-tree[1] 建立樹，並可以透過 git-ls-tree[1] 訪問其資料。兩個樹可以使用 git-diff-tree[1] 進行比較。

標籤使用 git-mktag[1] 建立，簽名可以使用 git-verify-tag[1] 驗證，儘管通常使用 git-tag[1] 更簡單。

高階操作，例如 git-commit[1] 和 git-restore[1]，透過在工作樹、索引和物件資料庫之間移動資料來工作。Git 提供了單獨執行這些步驟的低層操作。

通常，所有 Git 操作都在索引檔案上進行。有些操作**純粹**在索引檔案上工作（顯示索引的當前狀態），但大多數操作在索引檔案與資料庫或工作目錄之間移動資料。因此，有四種主要組合：

你可以使用各種輔助工具檢查物件資料庫和索引中表示的資料。對於每個物件，你可以使用 git-cat-file[1] 來檢查物件的詳細資訊：

顯示物件的型別，一旦你知道型別（通常在你找到物件的位置隱含），你可以使用：

來顯示其內容。注意！樹具有二進位制內容，因此有一個特殊的輔助工具用於顯示該內容，稱為 git ls-tree，它將二進位制內容轉換為更易於閱讀的形式。

檢視“提交”物件特別有啟發性，因為它們往往很小並且相當自解釋。特別是，如果你遵循在 .git/HEAD 中放置頂層提交名稱的約定，你可以這樣做：

來檢視頂層提交是什麼。

Git 可以幫助你執行三向合併，透過多次重複合併過程，這又可以用於多向合併。常見的情況是你只進行一次三向合併（協調兩條歷史線）並提交結果，但如果你願意，你可以一次性合併多個分支。

要執行三向合併，你需要從你想要合併的兩個提交開始，找到它們最近的共同父級（第三個提交），然後比較與這三個提交對應的樹。

要獲取合併的“基礎”，請查詢兩個提交的共同父級：

這會打印出它們都基於的提交名稱。你現在應該查詢這些提交的樹物件，這可以透過以下方式輕鬆完成：

因為樹物件資訊總是提交物件中的第一行。

一旦你知道要合併的三棵樹（一棵“原始”樹，也就是共同樹，以及兩棵“結果”樹，也就是你想合併的分支），你就可以將“合併”讀取到索引中。如果它必須丟棄你舊的索引內容，它會發出警告，所以你應該確保你已經提交了這些內容——事實上，你通常總是會根據你的最後一次提交進行合併（無論如何，這應該與你當前索引中的內容匹配）。

要執行合併，請執行：

這將在索引檔案中直接為你執行所有瑣碎的合併操作，你只需使用 git write-tree 寫入結果。

遺憾的是，許多合併並非微不足道。如果有檔案被新增、移動或刪除，或者如果兩個分支都修改了同一個檔案，你將得到一個包含“合併條目”的索引樹。這樣的索引樹無法寫入樹物件，你必須在使用其他工具解決任何此類合併衝突後，才能寫入結果。

你可以使用 git ls-files --unmerged 命令檢查此類索引狀態。示例：

git ls-files --unmerged 命令的每行輸出都以 blob 模式位、blob SHA-1、階段號和檔名開頭。階段號是 Git 表示其來源樹的方式：階段 1 對應於 $orig 樹，階段 2 對應於 HEAD 樹，階段 3 對應於 $target 樹。

前面我們提到，簡單的合併是在 git read-tree -m 內部完成的。例如，如果檔案從 $orig 到 HEAD 或 $target 沒有變化，或者如果檔案從 $orig 到 HEAD 以及從 $orig 到 $target 的變化方式相同，那麼最終結果顯然是 HEAD 中的內容。上述示例表明，檔案 hello.c 從 $orig 到 HEAD 以及從 $orig 到 $target 的變化方式不同。你可以透過在你喜歡的 3-way 合併程式（例如 diff3、merge 或 Git 自帶的 merge-file）上，自行處理來自這三個階段的 blob 物件來解決此問題，如下所示：

這會將合併結果留在 hello.c~2 檔案中，如果存在衝突，還會帶有衝突標記。在驗證合併結果合理後，你可以透過以下方式告訴 Git 此檔案的最終合併結果：

當一個路徑處於“未合併”狀態時，對該路徑執行 git update-index 會告訴 Git 將該路徑標記為已解決。

以上是 Git 最底層合併的描述，旨在幫助你理解其內部概念上發生了什麼。實際上，沒有人，甚至 Git 本身，會為此執行三次 git cat-file。有一個 git merge-index 程式，它將階段提取到臨時檔案，並在此檔案上呼叫一個“合併”指令碼：

更高級別的 git merge -s resolve 就是用這種方式實現的。

所有物件都具有靜態確定的“型別”，用於標識物件的格式（即如何使用它，以及它如何引用其他物件）。目前有四種不同的物件型別：“blob”、“tree”、“commit”和“tag”。

無論物件型別如何，所有物件都共享以下特性：它們都使用 zlib 進行壓縮，並帶有一個頭部，該頭部不僅指定了它們的型別，還提供了物件中資料的大小資訊。值得注意的是，用於命名物件的 SHA-1 雜湊是原始資料加上此頭部的雜湊，因此 sha1sum file 不會匹配 file 的物件名稱（最早的 Git 版本雜湊方式略有不同，但結論仍然相同）。

以下是一個簡短的示例，演示如何手動生成這些雜湊：

假設有一個包含簡單內容的小文字檔案：

現在我們可以手動生成 Git 會用於此檔案的雜湊：

可以使用 git hash-object 驗證此手動構建的雜湊，該命令當然會隱藏頭部的新增過程：

因此，物件的通用一致性總是可以獨立於物件的內容或型別進行測試：所有物件都可以透過驗證 (a) 它們的雜湊與檔案內容匹配，以及 (b) 物件成功解壓為位元組流，形成 <ascii-type-without-space> + <space> + <ascii-decimal-size> + <byte\0> + <binary-object-data> 序列來驗證。

結構化物件可以進一步驗證其結構和與其他物件的連線性。這通常透過 git fsck 程式完成，該程式生成所有物件的完整依賴圖，並驗證它們的內部一致性（除了僅透過雜湊驗證其表面一致性）。

對於新開發者來說，在 Git 原始碼中找到方向並非總是容易。本節為你提供一些指導，告訴你從何開始。

一個好的起點是檢視初始提交的內容：

初始修訂奠定了 Git 今天幾乎所有內容的基礎（儘管細節在某些地方可能有所不同），但它足夠小，可以一口氣讀完。

請注意，自該修訂以來，術語已發生變化。例如，該修訂中的 README 使用“changeset”一詞來描述我們現在所說的提交。

此外，我們不再稱之為“cache”（快取），而是“index”（索引）；但是，該檔案仍然名為 read-cache.h。

如果你理解了初始提交中的概念，你應該檢視一個較新的版本，並瀏覽 read-cache-ll.h、object.h 和 commit.h。

早期，Git（遵循 UNIX 傳統）是一組極其簡單的程式，你在指令碼中使用它們，將一個程式的輸出透過管道傳遞給另一個。這對初始開發很有利，因為它更容易測試新事物。然而，最近這些部分中的許多已經變成了內建命令，並且一些核心部分已經“庫化”，即為了效能、可移植性以及避免程式碼重複而被放入 libgit.a。

到目前為止，你已經知道索引是什麼（並且在 read-cache-ll.h 中找到相應的資料結構），並且知道只有幾種物件型別（blobs、trees、commits 和 tags），它們都從 struct object 繼承其通用結構，後者是它們的第一個成員（因此，你可以例如將 (struct object *)commit 強制轉換為與 &commit->object 相同的效果，即獲取物件名稱和標誌）。

現在是休息一下，讓這些資訊消化吸收的好時機。

下一步：熟悉物件命名。閱讀命名提交。有很多方式來命名一個物件（不僅僅是修訂版！）。所有這些都在 sha1_name.c 中處理。快速檢視函式 get_sha1()。很多特殊處理都是由諸如 get_sha1_basic() 之類的函式完成的。

這只是為了讓你進入 Git 最庫化的部分：修訂遍歷器（revision walker）。

基本上，git log 的初始版本是一個 shell 指令碼：

這意味著什麼？

git rev-list 是修訂遍歷器的原始版本，它總是將修訂列表列印到標準輸出。它仍然可用，並且需要如此，因為大多數新的 Git 命令都是從使用 git rev-list 的指令碼開始的。

git rev-parse 現在不再那麼重要了；它僅用於過濾出與指令碼呼叫的不同底層命令相關的選項。

git rev-list 所做的主要工作包含在 revision.c 和 revision.h 中。它將選項封裝在一個名為 rev_info 的結構體中，該結構體控制如何以及遍歷哪些修訂版等。

git rev-parse 的原始工作現在由函式 setup_revisions() 完成，它解析修訂版和修訂遍歷器的常用命令列選項。這些資訊儲存在結構體 rev_info 中，供以後使用。呼叫 setup_revisions() 後，你可以進行自己的命令列選項解析。之後，你必須呼叫 prepare_revision_walk() 進行初始化，然後可以使用函式 get_revision() 逐個獲取提交。

如果你對修訂遍歷過程的更多細節感興趣，只需檢視 cmd_log() 的首次實現；呼叫 git show v1.3.0~155^2~4 並向下滾動到該函式（請注意，你不再需要直接呼叫 setup_pager()）。

如今，git log 是一個內建命令，這意味著它包含在命令 git 中。一個內建命令的原始碼方面是：

有時，一個原始檔中包含多個內建命令。例如，cmd_whatchanged() 和 cmd_log() 都位於 builtin/log.c 中，因為它們共享相當多的程式碼。在這種情況下，那些不以其所在 .c 檔名命名的命令必須在 Makefile 的 BUILT_INS 中列出。

git log 在 C 語言中看起來比原始指令碼複雜，但這帶來了更大的靈活性和效能。

在這裡再次暫停一下是個不錯的時機。

第三課是：研究程式碼。真的，這是瞭解 Git 組織結構的最好方法（在你瞭解基本概念之後）。

那麼，思考一下你感興趣的事情，比如：“如何僅透過 blob 的物件名稱來訪問它？”第一步是找到一個可以實現此功能的 Git 命令。在本例中，它要麼是 git show，要麼是 git cat-file。

為了清晰起見，我們繼續使用 git cat-file，因為它：

因此，檢視 builtin/cat-file.c，搜尋 cmd_cat_file() 並檢視它的作用。

我們跳過顯而易見的細節；這裡唯一真正有趣的部分是對 get_sha1() 的呼叫。它嘗試將 argv[2] 解釋為物件名稱，如果它引用了當前倉庫中存在的物件，它會將生成的 SHA-1 寫入變數 sha1。

這裡有兩點值得注意：

你會在整個程式碼中看到這兩種情況。

現在，重點來了：

這就是你讀取 blob（實際上，不僅是 blob，而是任何型別的物件）的方式。要了解函式 read_object_with_reference() 實際如何工作，請查詢其原始碼（例如在 Git 倉庫中執行 git grep read_object_with | grep ":[a-z]"），然後閱讀原始碼。

要了解如何使用結果，只需繼續閱讀 cmd_cat_file()：

有時，你不知道在哪裡查詢某個特性。在許多此類情況下，透過搜尋 git log 的輸出，然後 git show 相應的提交，會有所幫助。

示例：如果你知道 git bundle 有一些測試用例，但想不起來它在哪裡（是的，你可以執行 git grep bundle t/，但這並不能說明重點！）：

在分頁器（less）中，只需搜尋“bundle”，回溯幾行，你就會看到它在提交 18449ab0 中。現在只需複製此物件名稱，並將其貼上到命令列中：

就是這樣。

另一個示例：找出如何將某個指令碼變為內建命令：

你看，Git 實際上是瞭解 Git 自身原始碼的最佳工具！

從 tarball 建立

從遠端倉庫建立

除了基於當前 HEAD 建立新分支（預設行為）外，還可以使用

同時建立並切換到新分支

更新並檢查你克隆自的倉庫中的分支

從不同的倉庫抓取一個分支，並在你的倉庫中為其指定一個新名稱

保留你經常使用的倉庫列表

搜尋迴歸

確保 Git 知道誰是負責人

選擇要包含在下一次提交中的檔案內容，然後進行提交

或者，一步完成提交的準備和建立

匯入或匯出補丁

在不同的Git倉庫中抓取一個分支，然後合併到當前分支

在合併到當前分支之前，將抓取的分支儲存到本地分支

在本地分支上建立提交後，使用你的提交更新遠端分支

當遠端分支和本地分支都命名為“test”時

常用遠端倉庫的快捷方式版本

檢查損壞

重新壓縮，移除未使用的垃圾

這是一項正在進行的工作。

基本要求

考慮如何建立一個清晰的章節依賴圖，這將允許人們在不必閱讀所有中間內容的情況下，直接跳轉到重要主題。

掃描Documentation/以查詢遺漏的其他內容；特別是：

掃描電子郵件存檔以查詢遺漏的其他內容

掃描手冊頁，檢視是否有任何內容假設了比本手冊提供的更多背景知識。

新增更多好的示例。完全由“食譜”式示例組成的章節可能是一個好主意；也許可以把“高階示例”部分作為章節的標準結尾部分？

在適當的地方包含到詞彙表的交叉引用。

新增一個關於與其他版本控制系統（包括CVS、Subversion以及單純的釋出tarball系列匯入）協作的章節。

編寫一個關於使用底層命令和編寫指令碼的章節。

替代方案、克隆 -reference 等。

更多關於從倉庫損壞中恢復的資訊。參見：https://lore.kernel.org/git/Pine.LNX.4.64.0702272039540.12485@woody.linux-foundation.org/ https://lore.kernel.org/git/Pine.LNX.4.64.0702141033400.3604@woody.linux-foundation.org/