在您閱讀本手冊時，擁有一個 Git 儲存庫來實驗會很有用。

取得儲存庫的最佳方式是使用 git-clone[1] 指令下載現有儲存庫的副本。如果您還沒有想到任何專案，以下是一些有趣的範例

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

clone 指令會建立一個以專案名稱 (以上範例中為 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 處於「分離 (detached)」狀態。

這是一種輕鬆檢視特定版本的方法，而無需為新分支建立名稱。如果您之後決定要建立這個版本的新分支 (或標籤)，仍然可以這麼做。

您複製時建立的「master」分支是您所複製的儲存庫中 HEAD 的副本。然而，該儲存庫可能也有其他分支，而您的本地儲存庫會保留追蹤每個遠端分支的分支，稱為遠端追蹤分支，您可以使用 git-branch[1] 的 -r 選項來檢視它們。

在這個範例中，「origin」被稱為遠端儲存庫，或簡稱「遠端」。從我們的角度來看，此儲存庫的分支稱為「遠端分支」。上面列出的遠端追蹤分支是在複製時根據遠端分支建立的，並將由 git fetch (因此 git pull) 和 git push 更新。請參閱 使用 git fetch 更新儲存庫 以了解詳細資訊。

您可能想在您自己的分支上建立其中一個遠端追蹤分支，就像您對標籤所做的一樣。

您也可以直接檢視 origin/todo 以檢視它或編寫一次性的修補程式。請參閱 分離的 HEAD。

請注意，「origin」這個名稱只是 Git 預設用來指稱您複製來源儲存庫的名稱。

分支、遠端追蹤分支和標籤都是對提交的參考。所有參考都以斜線分隔的路徑名稱命名，並以 refs 開頭；到目前為止我們使用的名稱實際上是簡寫。

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

(新建立的參考實際上儲存在 .git/refs 目錄中，位於其名稱給定的路徑下。然而，為了提高效率，它們也可以打包在單一檔案中；請參閱 git-pack-refs[1])。

另一個有用的快捷方式是，可以使用儲存庫的名稱來指稱該儲存庫的「HEAD」。因此，例如，「origin」通常是儲存庫「origin」中 HEAD 分支的簡寫。

有關 Git 檢查參考的完整路徑列表，以及當存在多個具有相同簡寫名稱的參考時，它用來決定選擇哪個參考的順序，請參閱 gitrevisions[7] 的「SPECIFYING REVISIONS」章節。

在您複製儲存庫並提交一些自己的變更後，您可能想要檢查原始儲存庫是否有更新。

git-fetch 指令，若不帶任何引數，將會把所有遠端追蹤分支更新為在原始儲存庫中找到的最新版本。它不會觸及您的任何分支，甚至不會觸及複製時為您建立的「master」分支。

您也可以使用 git-remote[1] 來追蹤來自您複製來源以外之儲存庫的分支。

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

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

如果您檢視檔案 .git/config，您會看到 Git 已新增一個新的段落。

這就是 Git 追蹤遠端分支的原因；您可以透過使用文字編輯器編輯 .git/config 來修改或刪除這些組態選項。(請參閱 git-config[1] 的「CONFIGURATION FILE」章節以了解詳細資訊。)

假設您專案的 2.6.18 版可以正常運作，但「master」的版本會崩潰。有時，尋找此類回歸原因的最佳方法是，對專案的歷史記錄執行暴力搜尋，以找出導致問題的特定提交。git-bisect[1] 指令可以幫助您做到這一點。

如果您在此時執行 git branch，您會看到 Git 已暫時將您移至「(no branch)」中。HEAD 現在已與任何分支分離，並直接指向一個可從「master」訪問但無法從 v2.6.18 訪問的提交 (提交 ID 為 65934)。編譯並測試它，看看它是否崩潰。假設它確實崩潰。然後

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

大約經過 13 次測試 (在本例中) 之後，它將會輸出有罪提交的提交 ID。然後，您可以使用 git-show[1] 檢查提交，找出是誰編寫的，並將包含提交 ID 的錯誤報告郵寄給他們。最後，執行

回到您之前的分支。

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

這將會執行 gitk 並用一個標示為「bisect」的標記來標記它選擇的提交。選擇附近看起來安全的提交，記下它的提交 ID，並使用以下命令檢視它：

然後測試，視情況執行 bisect good 或 bisect bad，然後繼續。

您可能只想告訴 Git 您想要略過目前的提交，而不是使用 git bisect visualize，然後使用 git reset --hard fb47ddb2db。

然而，在這種情況下，Git 可能最終無法分辨一些最早略過的提交和稍後的不良提交之間的第一個不良提交。

如果您有測試腳本可以分辨好與壞的提交，也有一些方法可以自動化 bisect 流程。請參閱 git-bisect[1] 以了解更多關於這和其他 git bisect 功能的資訊。

我們已經看到了幾種命名提交的方法：

還有更多；請參閱 gitrevisions[7] 手冊頁的「SPECIFYING REVISIONS」章節，以取得命名修訂版本的完整方法列表。以下是一些範例：

請記住，合併提交可能有多個父提交；預設情況下，^ 和 ~ 會跟隨提交中列出的第一個父提交，但您也可以選擇：

除了 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 會在一個名為「索引」的特殊暫存區中維護樹狀結構內容的快照。

一開始，索引的內容將與 HEAD 的內容相同。因此，顯示 HEAD 與索引之間差異的命令 git diff --cached 應該在此時產生沒有輸出。

修改索引很容易。

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

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

在每個步驟之後，您可以驗證

始終顯示 HEAD 和索引檔案之間的差異——這就是您現在建立提交時要提交的內容——並且

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

請注意，git add 始終只將檔案的目前內容新增到索引中；除非您再次對該檔案執行 git add，否則對同一個檔案的進一步變更將會被忽略。

當您準備好時，只需執行

並且 Git 將提示您輸入提交訊息，然後建立新的提交。請檢查以確保它看起來與您預期的一樣。

作為一個特殊的快捷方式，

將使用您已修改或刪除的任何檔案來更新索引並建立提交，所有步驟都在一步完成。

許多命令對於追蹤您即將提交的內容很有用。

您也可以使用 git-gui[1] 來建立提交、檢視索引和工作樹檔案中的變更，並單獨選擇差異區塊以包含在索引中（透過右鍵點擊差異區塊並選擇「為提交暫存區塊」）。

雖然不是必需的，但最好以一行簡短（不超過 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 提交。

如果您使用 gitk 檢查產生的提交，您會看到它有兩個父節點，一個指向目前分支的頂端，另一個指向其他分支的頂端。

當合併無法自動解決時，Git 會將索引和工作目錄置於一種特殊的狀態，讓您可以取得所有需要用來協助解決合併衝突的資訊。

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

此外，git-status[1] 會將這些檔案列為「未合併」，且有衝突的檔案會加入衝突標記，如下所示：

您只需要編輯檔案以解決衝突，然後執行：

請注意，提交訊息將會自動填入一些關於合併的資訊。通常，您可以直接使用這個預設訊息，無需修改，但如果需要，您也可以加入您自己的額外評論。

以上是您解決簡單合併衝突所需知道的所有資訊。但 Git 也提供更多資訊來協助解決衝突。

如果您遇到困難，並決定放棄並將所有混亂都拋棄，您可以隨時使用下列命令回到合併前的狀態：

或者，如果您已經提交了想要拋棄的合併，則可以使用：

但是，在某些情況下，最後這個命令可能會有危險——如果已經提交的提交本身可能已合併到另一個分支，請永遠不要拋棄已提交的提交，因為這樣做可能會使後續的合併更加混亂。

上面沒有提到一個特殊情況，會被以不同的方式處理。通常，合併會產生一個合併提交，有兩個父節點，每個父節點指向合併的兩個開發線條之一。

但是，如果目前分支是另一個分支的祖先——因此目前分支中存在的所有提交都已包含在另一個分支中——那麼 Git 只會執行「快轉」；目前分支的頭部會向前移動以指向合併進來的分支的頭部，而不會建立任何新的提交。

如果您搞砸了工作目錄，但尚未提交您的錯誤，您可以使用下列命令將整個工作目錄返回到上次提交的狀態：

如果您進行了一次後來希望自己沒有進行的提交，則有兩種根本不同的方法來解決問題：

在大型儲存庫中，Git 依賴壓縮來防止歷史資訊佔用過多磁碟或記憶體空間。某些 Git 命令可能會自動執行 git-gc[1]，因此您不必擔心手動執行它。然而，壓縮大型儲存庫可能需要一些時間，因此您可能需要明確呼叫 gc 以避免在不方便時觸發自動壓縮。

在您複製儲存庫並提交一些自己的變更後，您可能會希望檢查原始儲存庫是否有更新，並將它們合併到您自己的工作中。

我們已經了解 如何使用 git fetch[1] 讓遠端追蹤分支保持最新，以及如何合併兩個分支。因此，您可以使用以下方式從原始儲存庫的 master 分支合併變更：

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

事實上，如果您簽出了 master，則此分支已由 git clone 配置為從 origin 儲存庫的 HEAD 分支取得變更。因此，您通常只需使用簡單的

這個命令會從遠端分支抓取變更到您的遠端追蹤分支 origin/*，並將預設分支合併到目前分支中。

更一般地說，從遠端追蹤分支建立的分支預設會從該分支提取。請參閱 git-config[1] 中 branch.<name>.remote 和 branch.<name>.merge 選項的描述，以及 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

對於開發人員較少的專案，或用於同步一些私有儲存庫，這可能就是您所需要的全部。

但是，更常見的做法是維護一個單獨的公用儲存庫（通常在不同的主機上），供其他人從中提取變更。這通常更方便，並且允許您將正在進行的私人工作與公開可見的工作清楚地分開。

您將繼續在您的個人儲存庫中執行您的日常工作，但會定期將您個人儲存庫中的變更「推送」到您的公用儲存庫中，允許其他開發人員從該儲存庫中提取。因此，在有一個具有公用儲存庫的其他開發人員的情況下，變更的流程如下所示

我們將在以下章節中說明如何執行此操作。

淺層複製及其截斷的歷史記錄，當一個人只對專案的近期歷史記錄感興趣，而從上游取得完整歷史記錄的成本很高時很有用。

淺層複製是透過指定 git-clone[1] --depth 切換來建立的。之後可以使用 git-fetch[1] --depth 切換來變更深度，或使用 --unshallow 還原完整歷史記錄。

只要合併基準位於近期歷史記錄中，在淺層複製內合併即可運作。否則，它會像合併不相關的歷史記錄一樣，並且可能導致巨大的衝突。此限制可能會使此儲存庫不適合在以合併為基礎的工作流程中使用。

假設你是大型專案的貢獻者，你想要添加一個複雜的功能，並且以一種讓其他開發人員容易閱讀你的變更、驗證它們是否正確，並理解你進行每個變更的原因的方式，將其呈現給他們。

如果你將所有變更呈現為單一補丁（或提交），他們可能會覺得一次要消化太多資訊。

如果你將包含錯誤、修正和死胡同的完整工作歷史呈現給他們，他們可能會感到不知所措。

因此，理想情況通常是產生一系列補丁，使其滿足以下條件：

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

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

你沒有將任何合併合併到 mywork 中，所以它只是 origin 之上的一個簡單線性補丁序列。

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

此時，你可以使用 pull 將你的變更合併回來；結果會建立一個新的合併提交，如下所示：

但是，如果你希望將 mywork 中的歷史紀錄保持為一個簡單的提交系列，而沒有任何合併，你也可以選擇使用 git-rebase[1]。

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

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

Git 就會繼續套用其餘的補丁。

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

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

我們在 通過重寫歷史紀錄來修正錯誤 中看到，你可以使用以下指令來取代最近的提交：

這將用包含你的變更的新提交來取代舊提交，讓你首先有機會編輯舊的提交訊息。這對於修正上次提交中的錯字，或者調整錯誤暫存的提交的補丁內容非常有用。

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

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

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

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

將你目前的 HEAD rebase 到你想要保留原樣的最後一個提交。例如，如果你想要重新排序最近的 5 個提交，請使用：

這將開啟你的編輯器，其中列出了執行 rebase 的步驟。

如註解中所述，你可以通過編輯列表來重新排序提交、將它們壓縮在一起、編輯提交訊息等。一旦你感到滿意，請儲存列表並關閉編輯器，rebase 就會開始。

rebase 會在 pick 被取代為 edit 時，或者當列表中的步驟無法機械地解決衝突並需要你的協助時停止。當你完成編輯和/或解決衝突時，你可以使用 git rebase --continue 繼續。如果你認為事情變得太複雜，你始終可以使用 git rebase --abort 來取消。即使在 rebase 完成後，你仍然可以使用 reflog 來恢復原始分支。

有關程序和額外提示的更詳細討論，請參閱 git-rebase[1] 的「互動模式」部分。

還有許多其他工具，例如 StGit，它們的存在目的是為了維護補丁系列。這些不在本手冊的範圍內。

重寫分支歷史紀錄的主要問題與合併有關。假設有人提取你的分支並將其合併到他們的分支中，結果如下所示：

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

如果我們在一個儲存庫中一起檢查所有這些歷史紀錄，它會看起來像這樣：

Git 無法知道新的 head 是舊 head 的更新版本；它會將這種情況視為與兩位開發人員平行地在舊 head 和新 head 上獨立完成工作的情況完全相同。此時，如果有人嘗試將新 head 合併到他們的分支中，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 之間的歷史紀錄 rebase 到 A 之上，你將會得到這個線性歷史紀錄：

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

部分由於這個原因，許多經驗豐富的 Git 使用者，即使在一個以合併為主的專案上工作，也會通過在發布之前針對最新的上游版本進行 rebase 來保持歷史紀錄的線性。

除了使用 git-remote[1]，您也可以選擇一次僅更新一個分支，並將其以任意名稱儲存在本地。

第一個參數 origin，只是告訴 Git 從您最初複製的儲存庫中提取。第二個參數告訴 Git 從遠端儲存庫提取名為 todo 的分支，並將其以 refs/heads/my-todo-work 的名稱儲存在本地。

您也可以從其他儲存庫提取分支；因此，

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

在先前的範例中，當更新現有分支時，git fetch 會檢查遠端分支上的最新提交是否為您的分支副本上的最新提交的後代，然後才將您的分支副本更新為指向新的提交。Git 將此過程稱為快轉。

快轉看起來像這樣

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

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

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

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

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

請注意，舊版本的 example/master 所指向的提交可能會遺失，如我們在前一節中所見。

我們在上面看到 origin 只是指您最初複製的儲存庫的捷徑。此資訊儲存在 Git 設定變數中，您可以使用 git-config[1] 來檢視它們

如果有其他您也經常使用的儲存庫，您可以建立類似的設定選項以節省輸入；例如，

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

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

設定遠端之後，以下三個命令將執行相同的操作

請參閱 git-config[1] 以取得上述設定選項的更多詳細資訊，並參閱 git-fetch[1] 以取得 refspec 語法的更多詳細資訊。

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

（請參閱物件儲存格式以取得物件格式和 SHA-1 計算的詳細資訊。）

有四種不同的物件類型：「blob」、「tree」、「commit」和「tag」。

物件類型的更多詳細資訊

索引是一個二進位檔案（通常保存在 .git/index 中），其中包含一個已排序的路徑名稱清單，每個路徑名稱都具有權限和 blob 物件的 SHA-1；git-ls-files[1] 可以向您顯示索引的內容：

請注意，在較舊的文件中，您可能會看到索引稱為「目前目錄快取」或僅稱為「快取」。它有三個重要的屬性：

因此，索引是一種臨時的預備區域，其中填滿了您正在處理的 tree。

如果您完全清除索引，一般而言，只要您有它描述的 tree 的名稱，您就不會遺失任何資訊。

永遠要在發布父專案中參考的更改之前，發布子模組的更改。如果你忘記發布子模組的更改，其他人將無法克隆儲存庫。

在較舊的 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 向合併程式（例如 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 *檔案* 與 *檔案* 的物件名稱不符（最早版本的 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 使用「變更集」一詞來描述我們現在稱為的 commit。

此外，我們不再將其稱為「快取」，而是稱為「索引」；但是，該檔案仍然稱為 read-cache.h。

如果您掌握了初始提交中的想法，您應該查看較新版本並瀏覽 read-cache-ll.h、object.h 和 commit.h。

在早期，Git（遵循 UNIX 的傳統）是一堆非常簡單的程式，您可以在指令碼中使用它們，將一個程式的輸出傳送到另一個程式。這對於初始開發來說效果很好，因為它更容易測試新事物。但是，最近這些部分中的許多部分已成為內建程式，並且一些核心已「libified」，即為了效能、可攜性原因和避免程式碼重複而放入 libgit.a 中。

到目前為止，您已經知道索引是什麼（並在 read-cache-ll.h 中找到對應的資料結構），並且只有幾種類型的物件（blob、樹狀結構、提交和標籤）從 struct object 繼承其通用結構，這是它們的第一個成員（因此，您可以將 (struct object *)commit 轉換為與 &commit->object 達到 *相同* 的效果，即取得物件名稱和旗標）。

現在是休息一下，讓這些資訊沉澱的好時機。

下一步：熟悉物件命名。閱讀 命名提交。有很多種方式可以命名物件（而不僅僅是修訂版！）。所有這些都在 sha1_name.c 中處理。快速查看函式 get_sha1()。許多特殊處理都是由 get_sha1_basic() 或類似的函式完成的。

這只是為了讓您進入 Git 最 libified 部分的狀態：修訂版步行者。

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

這是什麼意思？

git rev-list 是修訂版步行者的原始版本，它 *總是* 將修訂版的清單列印到 stdout。它仍然可以正常運作，而且必須正常運作，因為大多數新的 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 對應的 commit 會很有幫助。

範例：如果你知道 git bundle 有一些測試案例，但不記得它在哪裡（是的，你可以 git grep bundle t/，但那並沒有說明重點！）

在分頁器 (less) 中，只需搜尋 "bundle"，然後往回幾行，就會看到它在 commit 18449ab0 中。現在只需複製這個物件名稱，並將它貼到命令列中

瞧！

另一個範例：找出為了讓某些腳本成為內建命令需要做什麼

你看，Git 實際上是找出 Git 原始碼的最佳工具！

從 tarball

從遠端儲存庫

不要將新分支基於目前的 HEAD（預設），請使用

同時建立並切換到新分支

更新並檢查從您複製的儲存庫中的分支

從不同的儲存庫提取分支，並在您的儲存庫中給它一個新名稱

保留您經常使用的儲存庫列表

搜尋回歸

確保 Git 知道要歸咎於誰

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

或者，一步準備並建立提交

匯入或匯出修補程式

提取不同 Git 儲存庫中的分支，然後合併到目前分支

在合併到目前分支之前，將提取的分支儲存到本機分支

在本機分支上建立提交之後，使用您的提交更新遠端分支

當遠端和本機分支都命名為「test」時

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

檢查是否損毀

重新壓縮、刪除未使用的垃圾

這是一個正在進行中的工作。

基本要求

思考如何建立清晰的章節相依性圖表，讓人們能夠在不必閱讀中間所有內容的情況下，就能找到重要的主題。

掃描 Documentation/ 目錄，找出遺漏的其他內容；特別是

掃描電子郵件存檔，找出遺漏的其他內容

掃描 man page，看看是否有任何頁面假設讀者具備比本手冊提供的更多背景知識。

添加更多好的範例。或許可以考慮加入全是範例的章節，或是把「進階範例」章節設為標準的章末環節？

適當時加入詞彙表的交叉參考。

新增一個章節，說明如何使用其他版本控制系統，包括 CVS、Subversion，以及直接匯入發布 tarball 系列。

撰寫一個關於使用底層指令和編寫腳本的章節。

替代方案，clone -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/