每個提交（除了專案中的第一個提交）都有一個父提交，該父提交顯示了此提交之前發生的事情。沿著父提交鏈最終會將您帶回專案的起點。

然而，提交併非構成一個簡單的列表；Git 允許開發線分叉然後重新匯合，而兩條開發線重新匯合的點稱為“合併”。因此，代表合併的提交可以有多個父提交，每個父提交代表導致該點的開發線中的最新提交。

瞭解這一點最佳方式是使用 gitk[1] 命令；現在在 Git 倉庫上執行 gitk 並查詢合併提交將有助於理解 Git 如何組織歷史。

在以下內容中，我們稱提交 X 從提交 Y“可達”，如果提交 X 是提交 Y 的祖先。等價地，您可以說 Y 是 X 的後代，或者存在一條從提交 Y 到提交 X 的父提交鏈。

我們將有時使用如下所示的圖表表示 Git 歷史。提交顯示為“o”，它們之間的連結用 - / 和 \ 繪製。時間從左到右。

如果我們需要討論某個特定的提交，字元“o”可能會被另一個字母或數字替換。

當我們需要精確時，我們將使用“分支”一詞來表示開發線，而“分支頭指標”（或簡稱為“頭指標”）來表示分支上最新提交的引用。在上例中，“A”這個分支頭指標指向一個特定的提交，但我們稱指向該點的三條提交線都屬於“分支 A”。

然而，當不會引起混淆時，我們經常同時使用“分支”一詞來表示分支和分支頭指標。

假設您想知道自 mybranch 從 origin 分叉以來，您在該分支上進行了多少次提交。

或者，您可能經常看到類似的事情使用底層命令 git-rev-list[1] 來完成，它只列出所有給定提交的 SHA-1。

假設您想檢查兩個分支是否指向相同的歷史點。

將告訴您兩個分支上的專案內容是否相同；然而，理論上，相同的專案內容可能透過兩種不同的歷史路線到達。您可以比較物件名稱。

或者，您可以回想一下 ... 運算子選擇的是可達於任一引用但非兩者都可達的提交；因此。

當兩個分支相同時，將不返回任何提交。

假設您知道提交 e05db0fd 修復了某個問題。您想找到包含該修復的最早標記的發行版。

當然，可能不止一個答案—​如果歷史在提交 e05db0fd 之後分叉，那麼可能存在多個“最早”的標記發行版。

您可以僅透過目視檢查自 e05db0fd 以來的提交。

或者您可以使用 git-name-rev[1]，它會根據指向提交後代的任何標籤為提交命名。

git-describe[1] 命令執行相反的操作，使用基於給定提交的標籤來命名修訂。

但這有時可以幫助您猜測哪些標籤可能出現在給定提交之後。

如果您只想驗證給定的標記版本是否包含給定的提交，您可以使用 git-merge-base[1]。

merge-base 命令查詢給定提交的共同祖先，並在一個提交是另一個的後代的情況下返回其中一個；因此，上面的輸出表明 e05db0fd 實際上是 v1.5.0-rc1 的祖先。

或者，請注意。

當且僅當 v1.5.0-rc1 包含 e05db0fd 時，將產生空輸出，因為它只輸出不可從 v1.5.0-rc1 可達的提交。

作為另一種選擇，git-show-branch[1] 命令列出從其引數可達的提交，並在左側顯示指示該提交可從哪些引數可達的指示器。因此，如果您執行類似。

那麼一行像。

表示 e05db0fd 可從自身、v1.5.0-rc1 和 v1.5.0-rc2 可達，但不可從 v1.5.0-rc0 可達。

假設您想檢視所有可從名為 master 的分支頭指標可達，但不能從您倉庫中的任何其他頭指標可達的提交。

我們可以使用 git-show-ref[1] 列出此倉庫中的所有頭指標。

我們可以獲取僅分支頭指標名稱，並使用 cut 和 grep 等標準實用程式刪除 master。

然後，我們可以要求顯示所有從 master 可達但從這些其他頭指標不可達的提交。

顯然，可能存在無數種變體；例如，要檢視可從某個頭指標可達但從倉庫中的任何標籤不可達的所有提交。

(參見 gitrevisions[7] 關於提交選擇語法的說明，例如 --not。)

git-archive 命令可以從專案的任何版本建立 tar 或 zip 歸檔；例如

將使用 HEAD 來生成一個 gzipped tar 歸檔，其中每個檔名都以 project/ 作為字首。如果可能，輸出檔案的格式會根據輸出檔案的副檔名來推斷，有關詳細資訊請參閱 git-archive[1]。

版本低於 1.7.7 的 Git 不支援 tar.gz 格式，您需要顯式地使用 gzip

如果您要釋出一個軟體專案的新版本，您可能希望同時建立一個變更日誌以包含在釋出公告中。

例如，Linus Torvalds 透過標記新核心版本，然後執行

其中 release-script 是一個 shell 指令碼，看起來像

然後他只是複製貼上輸出命令，在確認它們看起來沒問題後。

有人給了您一個檔案的副本，並詢問哪個提交修改了該檔案，使得該檔案在提交之前或之後包含給定的內容。您可以使用以下方法找出

這個命令的工作原理留給（高階）學生作為練習。git-log[1]、git-diff-tree[1] 和 git-hash-object[1] 的 man 頁可能會有所幫助。

Git 能夠自動合併的所有更改已新增到索引檔案中，因此 git-diff[1] 只顯示衝突。它使用一種不尋常的語法

回想一下，在解決此衝突後將要提交的提交將有兩個父提交，而不是通常的一個：一個父提交將是 HEAD，即當前分支的尖端；另一個將是另一個分支的尖端，它臨時儲存在 MERGE_HEAD 中。

在合併期間，索引中包含每個檔案的三個版本。這三個“檔案階段”中的每一個都代表了檔案的不同版本

當您要求 git-diff[1] 顯示衝突時，它會在工作樹中的衝突合併結果與階段 2 和 3 之間進行三方 diff，以僅顯示來自雙方的內容塊，混合在一起（換句話說，當一個塊的合併結果僅來自階段 2 時，該部分不衝突而不顯示。同一情況適用於階段 3）。

上面的 diff 顯示了 file.txt 的工作樹版本與階段 2 和階段 3 版本之間的差異。因此，而不是在每行前面加上一個單一的 + 或 -，它現在使用兩列：第一列用於第一個父提交和工作目錄副本之間的差異，第二列用於第二個父提交和工作目錄副本之間的差異。（有關格式的詳細資訊，請參閱 git-diff-files[1] 的“COMBINED DIFF FORMAT”部分。）

在以明顯的方式解決衝突後（但在更新索引之前），diff 將如下所示

這表明我們的已解決版本從第一個父提交中刪除了“Hello world”，從第二個父提交中刪除了“Goodbye”，並添加了“Goodbye world”，而後者以前在兩者中都不存在。

一些特殊的 diff 選項允許 diff 工作目錄與這些階段中的任何一個進行比較

當使用ort合併策略（預設）時，在用合併結果更新工作樹之前，Git 會寫入一個名為 AUTO_MERGE 的引用，該引用反映了它將要寫入的樹的狀態。文字衝突無法自動合併的路徑會像在工作樹中一樣，以衝突標記的形式寫入此樹。因此，AUTO_MERGE 可以與 git-diff[1] 一起使用，以顯示您為解決衝突所做的更改。使用與上面相同的示例，在解決衝突後，我們得到

請注意，diff 顯示我們刪除了衝突標記和內容行的兩個版本，而是寫入了“Goodbye world”。

git-log[1] 和 gitk[1] 命令也為合併提供了特殊幫助

這將顯示僅存在於 HEAD 或 MERGE_HEAD 中的所有提交，並且觸及了未合併的檔案。

您還可以使用 git-mergetool[1]，它允許您使用 Emacs 或 kdiff3 等外部工具合併未合併的檔案。

每次您解決一個檔案中的衝突並更新索引

該檔案的不同階段將被“摺疊”，之後 git diff（預設情況下）將不再顯示該檔案的 diff。

建立一個新提交來撤銷早期更改非常容易；只需將 git-revert[1] 命令指向有問題的提交；例如，要撤銷最新的提交

這將建立一個新的提交，該提交撤銷 HEAD 中的更改。您將有機會編輯新提交的提交訊息。

您也可以撤銷早期更改，例如，倒數第二個

在這種情況下，Git 將嘗試撤銷舊的更改，同時保持自那時以來的所有更改不變。如果最近的更改與要撤銷的更改重疊，那麼您將被要求手動修復衝突，就像在 解決合併 的情況下一樣。

如果出現問題的提交是最近的提交，並且您尚未公開該提交，那麼您可以透過 git reset --hard 來銷燬它。

或者，您可以像要 建立新提交 一樣，編輯工作目錄並更新索引來修復您的錯誤，然後執行

這將用包含您更改的新提交替換舊提交，讓您有機會先編輯舊的提交訊息。

同樣，您永遠不應該對可能已經合併到另一個分支的提交執行此操作；在這種情況下，請使用 git-revert[1]。

也可以替換歷史中更遠的提交，但這屬於高階主題，應留待 另一章。

在撤銷先前錯誤的更改時，您可能會發現使用 git-restore[1] 檢出檔案的舊版本很有用。命令

將 path/to/file 替換為它在 HEAD^ 提交中的內容，並更新索引以匹配。它不會更改分支。

如果您只想檢視檔案的舊版本，而不想修改工作目錄，您可以使用 git-show[1] 來完成

這將顯示給定版本的檔案。

當您正在處理複雜的事情時，發現了一個不相關的但明顯且微小的錯誤。您希望在繼續之前修復它。您可以使用 git-stash[1] 來儲存當前的工作狀態，然後在修復錯誤後（或選擇性地在不同的分支上進行修復，然後再返回），撤銷未完成的工作。

此命令會將您的更改儲存到 stash，並將您的工作樹和索引重置為與當前分支的尖端匹配。然後您可以像平常一樣進行修復。

之後，您可以使用 git stash pop 恢復到您正在進行的工作

git-fsck[1] 命令對倉庫執行一系列一致性檢查，並報告任何問題。這可能需要一些時間。

您將看到關於懸空物件的通知訊息。它們是仍然存在於倉庫中但不再被任何分支引用的物件，並且可以在一段時間後被 gc 移除（並且將會被移除）。您可以執行 git fsck --no-dangling 來抑制這些訊息，並仍然檢視真正的錯誤。

假設您的個人倉庫位於目錄 ~/proj 中。我們首先建立一個倉庫的新克隆，並告知 git daemon 它打算公開

生成的 proj.git 目錄包含一個“裸” Git 倉庫——​它只是 .git 目錄的內容，而沒有在其周圍檢出任何檔案。

接下來，將 proj.git 複製到您打算託管公共倉庫的伺服器上。您可以使用 scp、rsync 或任何最方便的方式。

這是首選方法。

如果有人另外管理伺服器，他們應該告訴您應將倉庫放在哪個目錄中，以及它將出現在哪個 git:// URL。然後您可以跳到下面的“將更改推送到公共倉庫”部分。

否則，您所要做的就是啟動 git daemon；它將監聽埠 9418。預設情況下，它允許訪問任何看起來像 Git 目錄且包含特殊檔案 git-daemon-export-ok 的目錄。將一些目錄路徑作為 git daemon 引數傳遞將進一步限制匯出的目錄到那些路徑。

您也可以將 git daemon 作為 inetd 服務執行；有關詳細資訊，請參閱 git-daemon[1] man 頁。（尤其請參閱示例部分。）

Git 協議提供更好的效能和可靠性，但對於已設定了 Web 伺服器的主機，HTTP 匯出可能更易於設定。

您所要做的就是將新建立的裸 Git 倉庫放在由 Web 伺服器匯出的目錄中，並進行一些調整以提供 Web 客戶端所需的一些額外資訊

（有關最後兩行的解釋，請參閱 git-update-server-info[1] 和 githooks[5]。）

宣佈 proj.git 的 URL。其他人應該能夠從該 URL 克隆或拉取，例如使用如下命令列

（另請參閱 setup-git-server-over-http，瞭解使用 WebDAV 的稍微更復雜的設定，該設定也允許透過 HTTP 推送。）

請注意，上面概述的兩種技術（透過 http 或 git 匯出）允許其他維護者獲取您的最新更改，但它們不允許寫入訪問，而您需要寫入訪問才能用您的私有倉庫建立的最新更改來更新公共倉庫。

最簡單的方法是使用 git-push[1] 和 ssh；要使用您名為 master 的分支的最新狀態更新名為 master 的遠端分支，請執行

或者只是

與 git fetch 類似，git push 會在不導致 快進 時報錯；請參閱下一節瞭解處理這種情況的詳細資訊。

請注意，push 的目標通常是 裸 倉庫。您也可以推送到具有已簽出工作樹的倉庫，但為了避免混淆，預設情況下會拒絕推送到更新當前已簽出分支的操作。有關詳細資訊，請參閱 git-config[1] 中 receive.denyCurrentBranch 選項的描述。

與 git fetch 類似，您也可以設定配置選項來節省輸入；所以，例如

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

這允許您使用以下命令執行相同的推送

有關詳細資訊，請參閱 remote..url、branch..remote 和 remote..push 選項在 git-config[1] 中的說明。

如果推送不會導致遠端分支 快進，那麼它將以類似以下的錯誤失敗

例如，這可能發生，如果您

您可以透過在分支名稱前加上加號來強制 git push 仍然執行更新。

注意加號 + 的新增。 或者，您可以使用 -f 標誌來強制遠端更新，如

通常，當公共倉庫中的分支頭髮生修改時，它會修改為指向之前指向的提交的後繼者。透過強制推送在這種情況下，您打破了這一慣例。（參見 重寫歷史的問題。）

儘管如此，這對於那些需要一種簡單方式來發布正在進行中的補丁系列的人來說是一種常見的做法，只要您警告其他開發人員您打算如何管理該分支，它就是一種可接受的折衷方案。

當其他人有權推送到同一個倉庫時，推送也可能以這種方式失敗。在這種情況下，正確的解決方案是在先更新工作後重試推送：可以透過 pull，或透過 fetch 後跟 rebase 來完成；有關更多資訊，請參見 下一節 和 gitcvs-migration[7]。

另一種協作方式是使用與 CVS 中常用的模型相似的模型，其中具有特殊許可權的幾位開發人員都推送到並從單個共享倉庫中拉取。有關如何設定此項的說明，請參見 gitcvs-migration[7]。

但是，雖然 Git 對共享倉庫的支援沒有任何問題，但這種操作模式通常不推薦，僅僅因為 Git 支援的協作模式——透過交換補丁和從公共倉庫拉取——與中央共享倉庫相比有許多優勢。

gitweb cgi 指令碼為使用者提供了一種簡單的方式來瀏覽專案的修訂、檔案內容和日誌，而無需安裝 Git。像 RSS/Atom feed 和 blame/annotation 詳細資訊這樣的功能可以被選擇性地啟用。

git-instaweb[1] 命令提供了一種使用 gitweb 瀏覽倉庫的簡單方法。使用 instaweb 時的預設伺服器是 lighttpd。

有關與具有 CGI 或 Perl 功能的伺服器進行永久安裝的詳細設定說明，請參見 Git 原始碼樹中的 gitweb/INSTALL 檔案和 gitweb[1]。

這描述了 Tony Luck 在他作為 Linux 核心 IA64 架構維護者的角色中如何使用 Git。

他使用兩個公共分支

他還使用一組臨時分支（“主題分支”），每個分支包含邏輯分組的補丁。

要進行設定，首先透過克隆 Linus 的公共樹來建立您的工作樹。

Linus 的樹將儲存在名為 origin/master 的遠端跟蹤分支中，並可以使用 git-fetch[1] 進行更新；您可以使用 git-remote[1] 設定“遠端”並使用 git-fetch[1] 來跟蹤其他公共樹並使其保持最新；請參見 倉庫和分支。

現在建立您將要工作的分支；這些分支最初位於 origin/master 分支的當前尖端，並且應該（使用 git-branch[1] 的 --track 選項）設定以預設合併 Linus 的更改。

可以使用 git-pull[1] 輕鬆地使它們保持最新。

重要提示！如果您在這些分支中有任何本地更改，那麼此合併將建立一個提交物件到歷史記錄中（如果沒有本地更改，Git 將簡單地執行“快進”合併）。許多人不喜歡這會在 Linux 歷史中產生的“噪音”，因此您應該在 release 分支中避免隨意執行此操作，因為當您要求 Linus 從 release 分支拉取時，這些帶有噪音的提交將成為永久歷史的一部分。

一些配置變數（參見 git-config[1]）可以輕鬆地將兩個分支推送到您的公共樹。（參見 設定公共倉庫。）

然後您可以使用 git-push[1] 推送 test 和 release 樹。

或者使用以下命令僅推送 test 和 release 分支中的一個。

或

現在應用來自社群的一些補丁。考慮一個簡短的、有吸引力的名稱來儲存此補丁（或一組相關補丁）的分支，並從 Linus 分支的一個最近的穩定標籤建立新分支。為您的分支選擇一個穩定的基礎將：1）幫助您：透過避免包含不相關且可能未經充分測試的更改；2）幫助未來的 bug 獵人使用 git bisect 來查詢問題。

現在應用補丁，執行一些測試，並提交更改。如果補丁是多部分系列，則應將其作為單獨的提交應用於此分支。

當您對更改的狀態滿意時，您可以將其合併到“test”分支中，以準備公開。

這裡不太可能發生衝突……但如果您在此步驟上花費了大量時間並且還從上游拉取了新版本，則可能會發生衝突。

過一段時間後，當有足夠的時間並且測試完成時，您可以將同一分支拉到 release 樹中，準備好向上遊提交。這就是您看到將每個補丁（或補丁系列）保留在其自己的分支中的價值的地方。這意味著補丁可以按任何順序移動到 release 樹中。

一段時間後，您將擁有許多分支，並且儘管您為每個分支選擇了精心設計的名稱，您可能會忘記它們的作用或它們的狀態。要獲得關於特定分支中包含哪些更改的提醒，請使用

要檢視它是否已合併到 test 或 release 分支中，請使用

或

（如果此分支尚未合併，您將看到一些日誌條目。如果已合併，則不會有輸出。）

一旦補丁完成了整個週期（從 test 移動到 release，然後被 Linus 拉取，最後回到您的本地 origin/master 分支），此更改的分支就不再需要了。當以下命令的輸出為空時，您會檢測到這一點。

此時可以刪除該分支。

有些更改非常微小，以至於不需要建立單獨的分支然後合併到 test 和 release 分支中。對於這些更改，只需直接應用於 release 分支，然後將其合併到 test 分支中。

將您的工作推送到 mytree 後，您可以使用 git-request-pull[1] 來準備一個“請拉取”請求訊息傳送給 Linus。

這裡有一些指令碼可以使這一切更加簡單。

“commit”物件將 tree 的物理狀態與如何到達那裡以及為什麼的描述聯絡起來。使用 --pretty=raw 選項來 git-show[1] 或 git-log[1] 來檢查您最喜歡的提交。

如您所見，提交由以下內容定義：

Note that a commit does not itself contain any information about what actually changed; all changes are calculated by comparing the contents of the tree referred to by this commit with the trees associated with its parents. In particular, Git does not attempt to record file renames explicitly, though it can identify cases where the existence of the same file data at changing paths suggests a rename. (See, for example, the -M option to git-diff[1]). 注意，提交本身不包含任何關於實際更改的資訊；所有更改都是透過比較此提交引用的樹的內容與其 parent 相關的樹的內容來計算的。特別是，Git 不會顯式記錄檔案重新命名，儘管它可以識別出在不同路徑下存在相同檔案資料的情況，這表明存在重新命名。（例如，請參閱 git-diff[1] 的 -M 選項）。

A commit is usually created by git-commit[1], which creates a commit whose parent is normally the current HEAD, and whose tree is taken from the content currently stored in the index. 提交通常由 git-commit[1] 建立，它建立一個 parent 通常是當前 HEAD 的提交，其 tree 取自當前儲存在索引中的內容。

The ever-versatile git-show[1] command can also be used to examine tree objects, but git-ls-tree[1] will give you more details. 萬能的 git-show[1] 命令也可以用來檢查 tree 物件，但 git-ls-tree[1] 會提供更多細節。

As you can see, a tree object contains a list of entries, each with a mode, object type, SHA-1 name, and name, sorted by name. It represents the contents of a single directory tree. 從圖中可以看到，一個 tree 物件包含一個條目列表，每個條目都具有模式、物件型別、SHA-1 名稱和名稱，並按名稱排序。它代表單個目錄樹的內容。

The object type may be a blob, representing the contents of a file, or another tree, representing the contents of a subdirectory. Since trees and blobs, like all other objects, are named by the SHA-1 hash of their contents, two trees have the same SHA-1 name if and only if their contents (including, recursively, the contents of all subdirectories) are identical. This allows Git to quickly determine the differences between two related tree objects, since it can ignore any entries with identical object names. 物件型別可以是 blob，代表檔案的內容，也可以是另一個 tree，代表子目錄的內容。由於 tree 和 blob，與其他所有物件一樣，都以其內容的 SHA-1 雜湊命名，因此兩個 tree 擁有相同的 SHA-1 名稱當且僅當它們的內容（包括遞迴地，所有子目錄的內容）相同。這使得 Git 能夠快速確定兩個相關 tree 物件之間的差異，因為它會忽略任何具有相同物件名稱的條目。

(Note: in the presence of submodules, trees may also have commits as entries. See Submodules for documentation.) （注意：在存在子模組的情況下，tree 也可能包含 commit 作為條目。有關文件，請參閱 Submodules。）

Note that the files all have mode 644 or 755: Git actually only pays attention to the executable bit. 請注意，檔案都具有 644 或 755 的許可權：Git 實際上只關注可執行位。

You can use git-show[1] to examine the contents of a blob; take, for example, the blob in the entry for COPYING from the tree above. 您可以使用 git-show[1] 檢查 blob 的內容；例如，從上面的 tree 中取 COPYING 條目中的 blob。

A "blob" object is nothing but a binary blob of data. It doesn’t refer to anything else or have attributes of any kind. 一個“blob”物件只不過是一塊二進位制資料。它不指向任何其他東西，也沒有任何型別的屬性。

Since the blob is entirely defined by its data, if two files in a directory tree (or in multiple different versions of the repository) have the same contents, they will share the same blob object. The object is totally independent of its location in the directory tree, and renaming a file does not change the object that file is associated with. 由於 blob 完全由其資料定義，因此如果目錄樹中的兩個檔案（或儲存庫的多個不同版本）具有相同的內容，它們將共享相同的 blob 物件。該物件完全獨立於其在目錄樹中的位置，重新命名檔案不會改變該檔案關聯的物件。

Note that any tree or blob object can be examined using git-show[1] with the <revision>:<path> syntax. This can sometimes be useful for browsing the contents of a tree that is not currently checked out. 請注意，任何 tree 或 blob 物件都可以使用 git-show[1] 和 <revision>:<path> 語法進行檢查。這有時對於瀏覽當前未簽出的 tree 的內容很有用。

If you receive the SHA-1 name of a blob from one source, and its contents from another (possibly untrusted) source, you can still trust that those contents are correct as long as the SHA-1 name agrees. This is because the SHA-1 is designed so that it is infeasible to find different contents that produce the same hash. 如果您從一個來源接收到 blob 的 SHA-1 名稱，並從另一個（可能不可信）來源接收到其內容，只要 SHA-1 名稱匹配，您仍然可以信任這些內容是正確的。這是因為 SHA-1 的設計使得找到生成相同雜湊的不同內容是不可能的。

Similarly, you need only trust the SHA-1 name of a top-level tree object to trust the contents of the entire directory that it refers to, and if you receive the SHA-1 name of a commit from a trusted source, then you can easily verify the entire history of commits reachable through parents of that commit, and all of those contents of the trees referred to by those commits. 同樣，您只需要信任頂級 tree 物件的檔名即可信任它引用的整個目錄的內容，如果您從受信任的來源接收到 commit 的 SHA-1 名稱，那麼您就可以輕鬆地驗證透過該 commit 的 parent 可達的所有 commit 歷史，以及那些 commit 引用的 tree 的所有內容。

So to introduce some real trust in the system, the only thing you need to do is to digitally sign just one special note, which includes the name of a top-level commit. Your digital signature shows others that you trust that commit, and the immutability of the history of commits tells others that they can trust the whole history. 因此，要在系統中引入真正的信任，您只需要做的是對一個特殊的說明進行數字簽名，該說明包含頂級 commit 的名稱。您的數字簽名向他人表明您信任該 commit，而 commit 歷史的不可變性則告訴他人他們可以信任整個歷史。

In other words, you can easily validate a whole archive by just sending out a single email that tells the people the name (SHA-1 hash) of the top commit, and digitally sign that email using something like GPG/PGP. 換句話說，您可以透過傳送一封電子郵件來輕鬆驗證整個存檔，該電子郵件告訴人們頂級 commit 的名稱（SHA-1 雜湊），並使用 GPG/PGP 等工具對該電子郵件進行數字簽名。

To assist in this, Git also provides the tag object…​ 為了協助此目的，Git 還提供了 tag 物件…

A tag object contains an object, object type, tag name, the name of the person ("tagger") who created the tag, and a message, which may contain a signature, as can be seen using git-cat-file[1]. 一個 tag 物件包含一個物件、物件型別、tag 名稱、建立 tag 的人（“tagger”）的姓名以及一條訊息，該訊息可能包含簽名，如使用 git-cat-file[1] 所見。

See the git-tag[1] command to learn how to create and verify tag objects. (Note that git-tag[1] can also be used to create "lightweight tags", which are not tag objects at all, but just simple references whose names begin with refs/tags/). 請參閱 git-tag[1] 命令瞭解如何建立和驗證 tag 物件。（注意：git-tag[1] 也可用於建立“輕量級 tag”，它們根本不是 tag 物件，而只是名稱以 refs/tags/ 開頭的簡單引用）。

Newly created objects are initially created in a file named after the object’s SHA-1 hash (stored in .git/objects). 新建立的物件最初會以物件的 SHA-1 雜湊命名（儲存在 .git/objects 中）的檔案形式建立。

Unfortunately this system becomes inefficient once a project has a lot of objects. Try this on an old project. 不幸的是，一旦專案包含大量物件，這種系統就會變得效率低下。在舊專案上嘗試此操作。

The first number is the number of objects which are kept in individual files. The second is the amount of space taken up by those "loose" objects. 第一個數字是保留在單個檔案中的物件數量。第二個數字是這些“鬆散”物件佔用的空間量。

You can save space and make Git faster by moving these loose objects in to a "pack file", which stores a group of objects in an efficient compressed format; the details of how pack files are formatted can be found in gitformat-pack[5]. 您可以透過將這些鬆散物件移至“pack 檔案”來節省空間並提高 Git 的速度，pack 檔案以高效的壓縮格式儲存一組物件；pack 檔案的格式詳情可以在 gitformat-pack[5] 中找到。

To put the loose objects into a pack, just run git repack. 要將鬆散物件放入 pack，只需執行 git repack。

This creates a single "pack file" in .git/objects/pack/ containing all currently unpacked objects. You can then run. 這會在 .git/objects/pack/ 中建立一個名為“pack 檔案”的檔案，其中包含所有當前未打包的物件。然後您可以執行。

to remove any of the "loose" objects that are now contained in the pack. This will also remove any unreferenced objects (which may be created when, for example, you use git reset to remove a commit). You can verify that the loose objects are gone by looking at the .git/objects directory or by running. 以刪除現在包含在 pack 中的任何“鬆散”物件。這還將刪除任何未引用的物件（例如，當您使用 git reset 刪除提交時可能會建立這些物件）。您可以透過檢視 .git/objects 目錄或執行來驗證鬆散物件是否已消失。

Although the object files are gone, any commands that refer to those objects will work exactly as they did before. 儘管物件檔案已消失，但任何引用這些物件的命令都會像以前一樣工作。

The git-gc[1] command performs packing, pruning, and more for you, so is normally the only high-level command you need. git-gc[1] 命令為您執行打包、修剪等操作，因此通常是您唯一需要的高階命令。

The git-fsck[1] command will sometimes complain about dangling objects. They are not a problem. git-fsck[1] 命令有時會抱怨懸空物件。它們不是問題。

The most common cause of dangling objects is that you’ve rebased a branch, or you have pulled from somebody else who rebased a branch—​see Rewriting history and maintaining patch series. In that case, the old head of the original branch still exists, as does everything it pointed to. The branch pointer itself just doesn’t, since you replaced it with another one. 懸空物件最常見的原因是您 rebase 了某個分支，或者您從 rebase 了某個分支的其他人那裡 pull 了——請參閱 Rewriting history and maintaining patch series。在這種情況下，原始分支的舊 head 仍然存在，它指向的所有內容也一樣。分支指標本身不存在了，因為您用另一個替換了它。

There are also other situations that cause dangling objects. For example, a "dangling blob" may arise because you did a git add of a file, but then, before you actually committed it and made it part of the bigger picture, you changed something else in that file and committed that updated thing—​the old state that you added originally ends up not being pointed to by any commit or tree, so it’s now a dangling blob object. 還有其他導致懸空物件的情況。例如，一個“懸空 blob”可能由於您添加了一個檔案，然後在您實際提交它並將其納入整體之前，您更改了該檔案中的其他內容並提交了更新的內容——您最初新增的舊狀態最終沒有被任何提交或 tree 指向，因此現在它是一個懸空 blob 物件。

Similarly, when the "ort" merge strategy runs, and finds that there are criss-cross merges and thus more than one merge base (which is fairly unusual, but it does happen), it will generate one temporary midway tree (or possibly even more, if you had lots of criss-crossing merges and more than two merge bases) as a temporary internal merge base, and again, those are real objects, but the end result will not end up pointing to them, so they end up "dangling" in your repository. 同樣，當“ort”合併策略執行時，發現存在交叉合併，從而有多個合併基（這相當罕見，但確實會發生），它將生成一個臨時中間 tree（如果有很多交叉合併和兩個以上的合併基，甚至可能更多）作為臨時的內部合併基，同樣，這些都是真實的物件，但最終結果不會指向它們，因此它們最終會“懸空”在您的儲存庫中。

Generally, dangling objects aren’t anything to worry about. They can even be very useful: if you screw something up, the dangling objects can be how you recover your old tree (say, you did a rebase, and realized that you really didn’t want to—​you can look at what dangling objects you have, and decide to reset your head to some old dangling state). 通常，懸空物件沒什麼可擔心的。它們甚至可能非常有用：如果您搞砸了什麼，懸空物件可以幫助您恢復舊的 tree（例如，您 rebase 了，並意識到您真的不想這樣做——您可以檢視您擁有的懸空物件，並決定將您的 HEAD 重置到某個舊的懸空狀態）。

For commits, you can just use. 對於 commit，您只需使用。

This asks for all the history reachable from the given commit but not from any branch, tag, or other reference. If you decide it’s something you want, you can always create a new reference to it, e.g. 這會查詢從給定 commit 可達但不可從任何分支、tag 或其他引用可達的所有歷史。如果您決定想要它，您可以隨時建立一個新的引用指向它，例如。

For blobs and trees, you can’t do the same, but you can still examine them. You can just do. 對於 blob 和 tree，您不能做同樣的事情，但仍然可以檢查它們。您可以直接執行。

to show what the contents of the blob were (or, for a tree, basically what the ls for that directory was), and that may give you some idea of what the operation was that left that dangling object. 以顯示 blob 的內容（或者，對於 tree，基本上是該目錄的 ls 輸出），這可能會讓您對導致該懸空物件的那個操作有所瞭解。

Usually, dangling blobs and trees aren’t very interesting. They’re almost always the result of either being a half-way mergebase (the blob will often even have the conflict markers from a merge in it, if you have had conflicting merges that you fixed up by hand), or simply because you interrupted a git fetch with ^C or something like that, leaving some of the new objects in the object database, but just dangling and useless. 通常，懸空 blob 和 tree 並不太有趣。它們幾乎總是以下情況的結果：要麼是半途的合併基（如果發生過沖突合併且您手動修復過，blob 甚至可能包含合併的衝突標記），要麼僅僅是因為您用 ^C 或類似的方式中斷了 git fetch，導致一些新物件留在物件資料庫中，但它們是懸空的且無用的。

Anyway, once you are sure that you’re not interested in any dangling state, you can just prune all unreachable objects. 無論如何，一旦您確定您對任何懸空狀態不感興趣，您就可以修剪所有不可達的物件。

and they’ll be gone. (You should only run git prune on a quiescent repository—​it’s kind of like doing a filesystem fsck recovery: you don’t want to do that while the filesystem is mounted. git prune is designed not to cause any harm in such cases of concurrent accesses to a repository but you might receive confusing or scary messages.) 它們就會消失。（您應該只在安靜的儲存庫上執行 git prune ——這有點像進行檔案系統 fsck 恢復：您不想在檔案系統掛載時進行此操作。git prune 的設計目的是在這種併發訪問儲存庫的情況下不會造成任何損害，但您可能會收到令人困惑或可怕的訊息。）

By design, Git treats data trusted to it with caution. However, even in the absence of bugs in Git itself, it is still possible that hardware or operating system errors could corrupt data. Git 的設計宗旨是謹慎對待其信任的資料。然而，即使 Git 本身沒有 bug，硬體或作業系統錯誤仍然可能損壞資料。

The first defense against such problems is backups. You can back up a Git directory using clone, or just using cp, tar, or any other backup mechanism. 防範此類問題的第一道防線是備份。您可以使用 clone 來備份 Git 目錄，或者直接使用 cp、tar 或任何其他備份機制。

As a last resort, you can search for the corrupted objects and attempt to replace them by hand. Back up your repository before attempting this in case you corrupt things even more in the process. 作為最後的手段，您可以搜尋損壞的物件並嘗試手動替換它們。在嘗試此操作之前，請備份您的儲存庫，以防您在此過程中使情況更加惡化。

We’ll assume that the problem is a single missing or corrupted blob, which is sometimes a solvable problem. (Recovering missing trees and especially commits is much harder). 我們假設問題是單個丟失或損壞的 blob，有時這是一個可解決的問題。（恢復丟失的 tree，尤其是 commit，會困難得多）。

Before starting, verify that there is corruption, and figure out where it is with git-fsck[1]; this may be time-consuming. 開始之前，請驗證是否存在損壞，並使用 git-fsck[1] 找出其位置；這可能很耗時。

Assume the output looks like this. 假設輸出如下所示。

Now you know that blob 4b9458b is missing, and that the tree 2d9263c6 points to it. If you could find just one copy of that missing blob object, possibly in some other repository, you could move it into .git/objects/4b/9458b3... and be done. Suppose you can’t. You can still examine the tree that pointed to it with git-ls-tree[1], which might output something like. 現在您知道 blob 4b9458b 丟失了，並且 tree 2d9263c6 指向它。如果您能找到那個丟失的 blob 物件的一個副本，可能在某個其他儲存庫中，您可以將其移動到 .git/objects/4b/9458b3... 並完成。假設您不能。您仍然可以使用 git-ls-tree[1] 檢查指向它的 tree，這可能會輸出類似以下內容：

So now you know that the missing blob was the data for a file named myfile. And chances are you can also identify the directory—​let’s say it’s in somedirectory. If you’re lucky the missing copy might be the same as the copy you have checked out in your working tree at somedirectory/myfile; you can test whether that’s right with git-hash-object[1]. 因此，現在您知道丟失的 blob 是名為 myfile 的檔案的內容。並且很有可能您也可以識別出目錄——假設它在 somedirectory 中。如果您幸運的話，丟失的副本可能與您在 somedirectory/myfile 的工作目錄中籤出的副本相同；您可以使用 git-hash-object[1] 來測試是否正確。

which will create and store a blob object with the contents of somedirectory/myfile, and output the SHA-1 of that object. if you’re extremely lucky it might be 4b9458b3786228369c63936db65827de3cc06200, in which case you’ve guessed right, and the corruption is fixed! 這將建立並存儲一個具有 somedirectory/myfile 內容的 blob 物件，並輸出該物件的 SHA-1。如果您非常幸運，它可能是 4b9458b3786228369c63936db65827de3cc06200，在這種情況下，您就猜對了，損壞就修復了！

Otherwise, you need more information. How do you tell which version of the file has been lost? 否則，您需要更多資訊。您如何確定丟失了哪個檔案版本？

The easiest way to do this is with. 最簡單的方法是使用。

Because you’re asking for raw output, you’ll now get something like. 因為您要求原始輸出，您現在會得到類似以下的內容。

This tells you that the immediately following version of the file was "newsha", and that the immediately preceding version was "oldsha". You also know the commit messages that went with the change from oldsha to 4b9458b and with the change from 4b9458b to newsha. 這告訴您，緊隨其後的檔案版本是“newsha”，而緊隨其前的版本是“oldsha”。您還知道與從 oldsha 到 4b9458b 的更改以及從 4b9458b 到 newsha 的更改相關的 commit 訊息。

If you’ve been committing small enough changes, you may now have a good shot at reconstructing the contents of the in-between state 4b9458b. 如果您提交的更改足夠小，您現在可能很有希望重建 4b9458b 之間的狀態內容。

If you can do that, you can now recreate the missing object with. 如果您能做到這一點，您現在就可以用…建立丟失的物件。

and your repository is good again! 您的儲存庫又好了！

(Btw, you could have ignored the fsck, and started with doing a. （順便說一句，您可以忽略 fsck，然後開始執行）。

and just looked for the sha of the missing object (4b9458b) in that whole thing. It’s up to you—​Git does have a lot of information, it is just missing one particular blob version. 並在其中查詢丟失物件的 sha（4b9458b）。這取決於您——Git確實有大量資訊，只是缺少一個特定的 blob 版本。

The git-update-index[1] command updates the index with information from the working directory. You generally update the index information by just specifying the filename you want to update, like so. git-update-index[1] 命令使用工作目錄中的資訊更新索引。您通常只需指定要更新的檔名即可更新索引資訊，例如。

but to avoid common mistakes with filename globbing etc., the command will not normally add totally new entries or remove old entries, i.e. it will normally just update existing cache entries. 但為了避免檔名通配等常見錯誤，該命令通常不會新增全新的條目或刪除舊的條目，也就是說，它通常只會更新現有的快取條目。

To tell Git that yes, you really do realize that certain files no longer exist, or that new files should be added, you should use the --remove and --add flags respectively. 要告訴 Git 是的，您確實意識到某些檔案已不存在，或者應該新增新檔案，您應該分別使用 --remove 和 --add 標誌。

NOTE! A --remove flag does not mean that subsequent filenames will necessarily be removed: if the files still exist in your directory structure, the index will be updated with their new status, not removed. The only thing --remove means is that update-index will be considering a removed file to be a valid thing, and if the file really does not exist any more, it will update the index accordingly. 注意！--remove 標誌不意味著後續檔名一定會被刪除：如果檔案仍然存在於您的目錄結構中，索引將更新為它們的新狀態，而不是被刪除。 --remove 僅表示 update-index 將考慮刪除的檔案是有效的內容，如果檔案確實不再存在，它將相應地更新索引。

As a special case, you can also do git update-index --refresh, which will refresh the "stat" information of each index to match the current stat information. It will not update the object status itself, and it will only update the fields that are used to quickly test whether an object still matches its old backing store object. 作為一種特殊情況，您還可以執行 git update-index --refresh，它將重新整理每個索引的“stat”資訊以匹配當前的 stat 資訊。它不會更新物件本身的狀態，並且它只會更新用於快速測試物件是否仍與其舊的後臺儲存物件匹配的欄位。

The previously introduced git-add[1] is just a wrapper for git-update-index[1]. 之前介紹的 git-add[1] 只是 git-update-index[1] 的一個包裝器。

You write your current index file to a "tree" object with the program. 您使用程式將當前的索引檔案寫入一個“tree”物件。

that doesn’t come with any options—​it will just write out the current index into the set of tree objects that describe that state, and it will return the name of the resulting top-level tree. You can use that tree to re-generate the index at any time by going in the other direction. 它沒有任何選項——它只會將當前索引寫入描述該狀態的 tree 物件集合，並返回結果的頂級 tree 的名稱。您可以在任何時候透過反向操作來使用該 tree 來重新生成索引。

You read a "tree" file from the object database, and use that to populate (and overwrite—​don’t do this if your index contains any unsaved state that you might want to restore later!) your current index. Normal operation is just. 您從物件資料庫讀取一個“tree”檔案，並使用它來填充（並覆蓋——如果您的索引包含任何您以後可能想恢復的未儲存狀態，請不要這樣做！）您的當前索引。正常操作只是。

and your index file will now be equivalent to the tree that you saved earlier. However, that is only your index file: your working directory contents have not been modified. 並且您的索引檔案現在將等同於您之前儲存的 tree。但是，那只是您的索引檔案：您的工作目錄內容尚未被修改。

You update your working directory from the index by "checking out" files. This is not a very common operation, since normally you’d just keep your files updated, and rather than write to your working directory, you’d tell the index files about the changes in your working directory (i.e. git update-index). 您透過“簽出”檔案來從索引更新您的工作目錄。這不是一個非常常見的操作，因為通常您會保持檔案更新，而不是寫入您的工作目錄，您會告訴索引檔案您工作目錄中的更改（即 git update-index）。

However, if you decide to jump to a new version, or check out somebody else’s version, or just restore a previous tree, you’d populate your index file with read-tree, and then you need to check out the result with. 但是，如果您決定跳轉到新版本，或簽出別人的版本，或僅恢復以前的 tree，您將使用 read-tree 填充您的索引檔案，然後您需要使用…簽出結果。

or, if you want to check out all of the index, use -a. 或者，如果您想簽出索引中的所有內容，請使用 -a。

NOTE! git checkout-index normally refuses to overwrite old files, so if you have an old version of the tree already checked out, you will need to use the -f flag (before the -a flag or the filename) to force the checkout. 注意！git checkout-index 通常拒絕覆蓋舊檔案，因此如果您已經簽出了舊版本的 tree，您將需要使用 -f 標誌（在 -a 標誌或檔名之前）來強制簽出。

Finally, there are a few odds and ends which are not purely moving from one representation to the other. 最後，還有一些零散的東西，它們不是純粹地從一種表示形式移動到另一種形式。

要提交您透過 git write-tree 例項化出來的樹，您需要建立一個“提交”物件，該物件引用該樹以及其背後的歷史記錄——最重要的是，它引用了在歷史記錄中排在其前面的“父”提交。

通常，“提交”只有一個父提交：在某個更改發生之前的樹的先前狀態。但是，有時它可能有兩個或更多父提交，在這種情況下，我們稱之為“合併”，因為這種提交會將由其他提交表示的兩個或多個先前狀態“合併”在一起。

換句話說，雖然“樹”表示工作目錄的特定目錄狀態，“提交”表示該狀態在時間軸上的位置，並解釋了我們是如何到達那裡的。

您透過提供描述提交時狀態的樹以及父提交列表來建立一個提交物件

然後透過標準輸入（透過管道重定向或檔案，或者直接在終端輸入）提供提交原因。

git commit-tree 將返回表示該提交的物件名稱，您應該將其儲存以備後用。通常，您會提交一個新的 HEAD 狀態，雖然 Git 不關心您將該狀態的說明儲存在哪裡，但在實踐中，我們傾向於將結果寫入 .git/HEAD 指向的檔案，以便我們始終可以看到最後一次提交的狀態。

這是一張圖，說明了各個部分如何組合在一起