Git
English ▾ 主題 ▾ 最新版本 ▾ git-log 最後更新於 2.46.0

名稱

git-log - 顯示提交紀錄

概要

git log [<options>] [<revision-range>] [[--] <path>…​]

描述

顯示提交紀錄。

列出從給定的提交(commit)追蹤 parent 連結可到達的提交,但排除從前方帶有 ^ 符號的提交可到達的提交。預設情況下,輸出會依反向時間順序排列。

您可以將此視為集合運算。從命令列給定的任何提交可到達的提交形成一個集合,然後從前方帶有 ^ 符號的任何提交可到達的提交將從該集合中減去。剩餘的提交會出現在命令的輸出中。可以使用各種其他選項和路徑參數來進一步限制結果。

因此,以下命令

$ git log foo bar ^baz

表示「列出所有從 foobar 可到達,但不是從 baz 可到達的提交」。

特殊符號 "<commit1>..<commit2>" 可以用作 "^<commit1> <commit2>" 的簡寫。例如,以下任一項可以互換使用

$ git log origin..HEAD
$ git log HEAD ^origin

另一個特殊符號是 "<commit1>…​<commit2>",這對於合併很有用。提交的結果集是兩個運算元之間的對稱差。以下兩個命令是等效的

$ git log A B --not $(git merge-base --all A B)
$ git log A...B

該命令採用適用於 git-rev-list[1] 命令的選項來控制顯示的內容和方式,以及適用於 git-diff[1] 命令的選項來控制如何顯示每個提交引入的變更。

選項

--follow

繼續列出檔案的歷史記錄,超出重新命名 (僅適用於單一檔案)。

--no-decorate
--decorate[=short|full|auto|no]

列印出顯示的任何提交的 ref 名稱。如果指定 short,則不會列印 ref 名稱前綴 refs/heads/refs/tags/refs/remotes/。如果指定 full,則會列印完整的 ref 名稱 (包括前綴)。如果指定 auto,那麼如果輸出要發送到終端機,ref 名稱會像給定 short 一樣顯示,否則不會顯示 ref 名稱。選項 --decorate--decorate=short 的簡寫。如果已配置,則預設為 log.decorate 的配置值,否則為 auto

--decorate-refs=<pattern>
--decorate-refs-exclude=<pattern>

對於每個候選參照,如果它符合提供給 --decorate-refs-exclude 的任何模式,或者它不符合提供給 --decorate-refs 的任何模式,則不要將它用於裝飾。 log.excludeDecoration 設定選項允許從裝飾中排除 refs,但明確的 --decorate-refs 模式會覆蓋 log.excludeDecoration 中的匹配。

如果沒有給定這些選項或設定,則如果參照符合 HEADrefs/heads/refs/remotes/refs/stash/refs/tags/,則將它們用作裝飾。

--clear-decorations

指定時,此選項會清除所有先前的 --decorate-refs--decorate-refs-exclude 選項,並放寬預設的裝飾篩選,以包含所有參照。如果配置值 log.initialDecorationSet 設定為 all,則會假設此選項。

--source

列印出命令列上給定的 ref 名稱,每個提交都是由此到達的。

--[no-]mailmap
--[no-]use-mailmap

使用 mailmap 檔案將作者和提交者名稱和電子郵件地址對應到正規的真實姓名和電子郵件地址。請參閱 git-shortlog[1]

--full-diff

如果沒有此旗標,git log -p <path>... 會顯示觸及指定路徑的提交,以及有關相同指定路徑的 diff。有了這個,會顯示觸及指定路徑的提交的完整 diff;這表示 "<path>…​" 只會限制提交,而不會限制這些提交的 diff。

請注意,這會影響所有基於 diff 的輸出類型,例如 --stat 等產生的類型。

--log-size

在每個提交的輸出中包含一行「log size <number>」,其中 <number> 是該提交訊息的長度 (以位元組為單位)。旨在加速從 git log 輸出讀取記錄訊息的工具,允許它們預先配置空間。

-L<start>,<end>:<file>
-L:<funcname>:<file>

追蹤由 <start>,<end> 給定的行範圍的演變,或由函數名稱正規表示式 <funcname><file> 內。您不得給予任何路徑規格限制器。目前僅限於從單一修訂開始的步行,也就是說,您只能給予零個或一個正修訂引數,且 <start><end> (或 <funcname>) 必須存在於起始修訂中。您可以多次指定此選項。暗示 --patch。可以使用 --no-patch 抑制修補程式輸出,但目前未實作其他 diff 格式 (即 --raw--numstat--shortstat--dirstat--summary--name-only--name-status--check)。

<start><end> 可以採用下列其中一種形式

  • 數字

    如果 <start><end> 是數字,則它會指定絕對行號 (行數從 1 開始計算)。

  • /regex/

    此表單將使用符合給定 POSIX 正規表示式的第一行。如果 <start> 是正規表示式,它將從先前的 -L 範圍的結尾搜尋,如果沒有,則從檔案的開頭搜尋。如果 <start>^/regex/,則會從檔案的開頭搜尋。如果 <end> 是正規表示式,它將從 <start> 給定的行開始搜尋。

  • +偏移量 或 -偏移量

    這僅對 <end> 有效,並且會指定在 <start> 給定的行之前或之後的行數。

如果在 <start><end> 的位置給定 :<funcname>,它是一個正規表示式,表示從符合 <funcname> 的第一個 funcname 行到下一個 funcname 行的範圍。 :<funcname> 從先前的 -L 範圍的結尾搜尋,如果沒有,則從檔案的開頭搜尋。 ^:<funcname> 從檔案的開頭搜尋。函數名稱的判斷方式與 git diff 處理修補程式區塊標頭的方式相同 (請參閱 gitattributes[5] 中的 *定義自訂區塊標頭*)。

<revision-range>

僅顯示指定修訂範圍中的提交。如果未指定 <revision-range>,則預設為 HEAD (即通往目前提交的整個歷史記錄)。 origin..HEAD 指定從目前提交 (即 HEAD) 可到達,但不是從 origin 可到達的所有提交。如需拼寫 <revision-range> 的完整方法清單,請參閱 gitrevisions[7] 的 *指定範圍* 區段。

[--] <path>…​

僅顯示足以說明指定路徑檔案如何產生的提交。詳細資訊和其他簡化模式請參閱下方的「歷史簡化」。

當產生混淆時,路徑可能需要加上 -- 前綴,以將其與選項或修訂範圍分隔開來。

提交限制

除了使用說明中解釋的特殊符號來指定應該列出的提交範圍外,還可以應用額外的提交限制。

一般來說,使用更多選項會進一步限制輸出(例如,--since=<date1> 會限制為晚於 <date1> 的提交,而與 --grep=<pattern> 一起使用會進一步限制為日誌訊息中包含符合 <pattern> 的行的提交),除非另有說明。

請注意,這些限制會在提交排序和格式化選項(例如 --reverse)之前應用。

-<數字>
-n <數字>
--max-count=<數字>

限制要輸出的提交數量。

--skip=<數字>

在開始顯示提交輸出之前,跳過 數字 個提交。

--since=<日期>
--after=<日期>

顯示晚於特定日期的提交。

--since-as-filter=<日期>

顯示晚於特定日期的所有提交。這會訪問範圍內的所有提交,而不是在第一個早於特定日期的提交處停止。

--until=<日期>
--before=<日期>

顯示早於特定日期的提交。

--author=<模式>
--committer=<模式>

將輸出限制為作者/提交者標頭行符合指定模式(正規表示式)的提交。使用多個 --author=<模式> 時,會選擇作者符合任何給定模式的提交(--committer=<模式> 也是如此)。

--grep-reflog=<模式>

將輸出限制為 reflog 條目符合指定模式(正規表示式)的提交。使用多個 --grep-reflog 時,會選擇 reflog 訊息符合任何給定模式的提交。除非使用 --walk-reflogs,否則使用此選項是錯誤的。

--grep=<模式>

將輸出限制為日誌訊息符合指定模式(正規表示式)的提交。使用多個 --grep=<模式> 時,會選擇訊息符合任何給定模式的提交(但請參閱 --all-match)。

--notes 生效時,會將來自註解的訊息視為日誌訊息的一部分進行比對。

--all-match

將輸出限制為符合所有給定 --grep 的提交,而不是至少符合一個的提交。

--invert-grep

將輸出限制為日誌訊息不符合 --grep=<模式> 指定模式的提交。

-i
--regexp-ignore-case

比對限制模式的正規表示式時,忽略字母大小寫。

--basic-regexp

將限制模式視為基本正規表示式;這是預設值。

-E
--extended-regexp

將限制模式視為延伸正規表示式,而不是預設的基本正規表示式。

-F
--fixed-strings

將限制模式視為固定字串(不將模式解讀為正規表示式)。

-P
--perl-regexp

將限制模式視為與 Perl 相容的正規表示式。

支援這些類型的正規表示式是編譯時的可選相依性。如果 Git 在編譯時未提供對它們的支援,則提供此選項將會導致其終止。

--remove-empty

當給定路徑從樹狀結構中消失時停止。

--merges

僅列印合併提交。這與 --min-parents=2 完全相同。

--no-merges

不列印有多個父提交的提交。這與 --max-parents=1 完全相同。

--min-parents=<數字>
--max-parents=<數字>
--no-min-parents
--no-max-parents

僅顯示具有至少(或最多)那麼多父提交的提交。特別地,--max-parents=1--no-merges 相同,--min-parents=2--merges 相同。--max-parents=0 會給出所有根提交,而 --min-parents=3 會給出所有章魚合併。

--no-min-parents--no-max-parents 會再次重設這些限制(為無限制)。等效形式為 --min-parents=0(任何提交都有 0 個或多個父項)和 --max-parents=-1(負數表示沒有上限)。

--first-parent

在尋找要包含的提交時,在看到合併提交時,僅追蹤第一個父提交。當檢視特定主題分支的演變時,此選項可以提供更好的概觀,因為合併到主題分支中往往只是為了不時地調整為更新的上游,而此選項可讓您忽略由這類合併帶入歷史記錄中的個別提交。

此選項也會將合併提交的預設差異格式變更為 first-parent,詳細資訊請參閱 --diff-merges=first-parent

--exclude-first-parent-only

在尋找要排除的提交(使用 ^)時,在看到合併提交時,僅追蹤第一個父提交。可用於找出主題分支從與遠端分支分歧點開始的變更集合,因為任意合併可以是有效的主題分支變更。

--not

反轉所有後續修訂指定器(直到下一個 --not 為止)的 ^ 前綴(或缺少前綴)的含義。當在 --stdin 之前在命令列上使用時,透過 stdin 傳遞的修訂將不受其影響。相反地,當透過標準輸入傳遞時,在命令列上傳遞的修訂將不受其影響。

--all

假裝好像 refs/ 中的所有 refs 以及 HEAD 都以 <commit> 的形式在命令列上列出。

--branches[=<模式>]

假裝好像 refs/heads 中的所有 refs 都以 <commit> 的形式在命令列上列出。如果給定 <模式>,則將分支限制為符合給定的 shell glob 的分支。如果模式缺少 ?*[,則隱含在結尾加上 /*

--tags[=<模式>]

假裝好像 refs/tags 中的所有 refs 都以 <commit> 的形式在命令列上列出。如果給定 <模式>,則將標籤限制為符合給定的 shell glob 的標籤。如果模式缺少 ?*[,則隱含在結尾加上 /*

--remotes[=<模式>]

假裝好像 refs/remotes 中的所有 refs 都以 <commit> 的形式在命令列上列出。如果給定 <模式>,則將遠端追蹤分支限制為符合給定的 shell glob 的分支。如果模式缺少 ?*[,則隱含在結尾加上 /*

--glob=<glob-模式>

假裝好像所有符合 shell glob <glob-模式> 的 refs 都以 <commit> 的形式在命令列上列出。如果缺少,會自動在前面加上 refs/。如果模式缺少 ?*[,則隱含在結尾加上 /*

--exclude=<glob-模式>

不包含下一個 --all--branches--tags--remotes--glob 否則會考慮的符合 <glob-模式> 的 refs。此選項的重複會累加排除模式,直到下一個 --all--branches--tags--remotes--glob 選項(其他選項或引數不會清除累加的模式)。

當分別套用至 --branches--tags--remotes 時,給定的模式不應以 refs/headsrefs/tagsrefs/remotes 開頭,而且當套用至 --glob--all 時,它們必須以 refs/ 開頭。如果想要在結尾加上 /*,則必須明確給出。

--exclude-hidden=[fetch|receive|uploadpack]

不要包含會被 git-fetchgit-receive-packgit-upload-pack 隱藏的 refs,方法是查閱適當的 fetch.hideRefsreceive.hideRefsuploadpack.hideRefs 設定以及 transfer.hideRefs (請參閱 git-config[1])。此選項會影響下一個虛擬參考選項 --all--glob,並在處理它們後清除。

--reflog

假裝好像 reflog 中提及的所有物件都以 <commit> 的形式在命令列上列出。

--alternate-refs

假裝好像備用儲存庫的 ref 提示中提及的所有物件都在命令列上列出。備用儲存庫是其物件目錄在 objects/info/alternates 中指定的任何儲存庫。包含的物件集合可以由 core.alternateRefsCommand 等修改。請參閱 git-config[1]

--single-worktree

依預設,當有多個工作樹時(請參閱 git-worktree[1]),下列選項將會檢查所有工作樹:--all--reflog--indexed-objects。此選項會強制它們僅檢查目前的工作樹。

--ignore-missing

當在輸入中看到無效的物件名稱時,假裝好像未給出錯誤的輸入。

--bisect

假裝好像列出了不良二分參考 refs/bisect/bad,並且後面接著 --not 以及命令列上的良好二分參考 refs/bisect/good-*

--stdin

除了從命令列取得引數外,也從標準輸入讀取引數。這接受 commit 和虛擬選項,例如 --all--glob=。當看到 -- 分隔符號時,後續輸入會被視為路徑,並用於限制結果。透過標準輸入讀取的旗標(例如 --not)僅對以相同方式傳遞的引數有效,且不會影響任何後續的命令列引數。

--cherry-mark

類似於 --cherry-pick(請參閱下方),但以 = 標記等效的 commit,而不是省略它們,並以 + 標記不等效的 commit。

--cherry-pick

當 commit 集合以對稱差值限制時,省略任何引入與「另一側」commit 相同變更的 commit。

例如,如果您有兩個分支 AB,要列出僅在其中一側的所有 commit,常用的方法是使用 --left-right(請參閱下方 --left-right 選項描述中的範例)。然而,它會顯示從另一個分支挑選過的 commit(例如,「b 上的第三個 commit」可能是從分支 A 挑選過來的)。使用此選項,會從輸出中排除此類 commit 配對。

--left-only
--right-only

僅列出對稱差值各自側的 commit,也就是那些會被 --left-right 標記為 <> 的 commit。

例如,--cherry-pick --right-only A...B 會省略 B 中那些在 A 中或與 A 中 commit 等效的 commit。換句話說,這會列出 git cherry A B 中的 + commit。更精確地說,--cherry-pick --right-only --no-merges 會給出確切的清單。

--cherry

--right-only --cherry-mark --no-merges 的同義詞;適用於將輸出限制為我們這一側的 commit,並標記那些已應用於分叉歷史另一側的 commit,使用 git log --cherry upstream...mybranch,類似於 git cherry upstream mybranch

-g
--walk-reflogs

不要追蹤 commit 的祖先鏈,而是從最新的到較舊的追蹤 reflog 條目。當使用此選項時,您無法指定要排除的 commit(也就是說,不能使用 *^commit*、*commit1..commit2* 和 *commit1...commit2* 標記法)。

使用 --pretty 格式(除了 onelinereference(原因顯而易見))時,這會導致輸出包含從 reflog 取得的額外兩行資訊。輸出中的 reflog 指示符可能會顯示為 ref@{<Nth>}(其中 *<Nth>* 是 reflog 中的反向時間順序索引)或 ref@{<timestamp>}(具有該條目的 *<timestamp>*),這取決於一些規則

  1. 如果起點指定為 ref@{<Nth>},則顯示索引格式。

  2. 如果起點指定為 ref@{now},則顯示時間戳記格式。

  3. 如果兩者都未使用,但命令列上給定了 --date,則以 --date 要求的格式顯示時間戳記。

  4. 否則,顯示索引格式。

--pretty=oneline 下,commit 訊息會以相同行上的此資訊作為前綴。此選項不能與 --reverse 結合使用。另請參閱 git-reflog[1]

--pretty=reference 下,此資訊完全不會顯示。

--merge

顯示範圍 HEAD...<other> 中接觸到衝突路徑的 commit,其中 <other>MERGE_HEADCHERRY_PICK_HEADREVERT_HEADREBASE_HEAD 中第一個存在的虛擬參考。僅當索引具有未合併的條目時才有效。此選項可用於在解決三方合併的衝突時顯示相關的 commit。

--boundary

輸出排除的邊界 commit。邊界 commit 會加上 - 作為前綴。

歷史簡化

有時您只對部分歷史記錄感興趣,例如修改特定 <path> 的 commit。但「歷史簡化」有兩個部分,一部分是選擇 commit,另一部分是如何執行它,因為簡化歷史記錄有各種策略。

以下選項選擇要顯示的 commit

<paths>

選取修改給定 <paths> 的 commit。

--simplify-by-decoration

選取由某些分支或標籤引用的 commit。

請注意,可能會顯示額外的 commit 以提供有意義的歷史記錄。

以下選項會影響簡化的執行方式

預設模式

將歷史簡化為最簡單的歷史記錄,以解釋樹狀結構的最終狀態。最簡單是因為如果最終結果相同(也就是說,合併具有相同內容的分支),它會修剪一些側分支。

--show-pulls

包含預設模式的所有 commit,以及任何與第一個父 commit 不是 TREESAME,但與後來的父 commit 是 TREESAME 的合併 commit。此模式有助於顯示「首次引入」變更到分支的合併 commit。

--full-history

與預設模式相同,但不修剪一些歷史記錄。

--dense

僅顯示選取的 commit,加上一些提供有意義歷史記錄的 commit。

--sparse

顯示簡化歷史記錄中的所有 commit。

--simplify-merges

--full-history 的額外選項,可從產生的歷史記錄中移除一些不必要的合併,因為沒有選取的 commit 對此合併有所貢獻。

--ancestry-path[=<commit>]

當給定要顯示的 commit 範圍時(例如,commit1..commit2commit2 ^commit1),僅顯示該範圍內是 <commit> 的祖先、<commit> 的後代或 <commit> 本身的 commit。如果未指定 commit,則使用 *commit1*(範圍中排除的部分)作為 <commit>。可以多次傳遞;如果是這樣,如果 commit 是給定的任何 commit,或是其中一個 commit 的祖先或後代,則會包含該 commit。

下面是更詳細的說明。

假設您指定 foo 作為 <paths>。我們將修改 foo 的 commit 稱為 !TREESAME,其餘稱為 TREESAME。(在為 foo 過濾的 diff 中,它們看起來分別不同和相等。)

在以下內容中,我們將始終參考相同的範例歷史記錄來說明簡化設定之間的差異。我們假設您正在此 commit 圖表中篩選檔案 foo

	  .-A---M---N---O---P---Q
	 /     /   /   /   /   /
	I     B   C   D   E   Y
	 \   /   /   /   /   /
	  `-------------'   X

歷史記錄 A---Q 的水平線被視為每個合併的第一個父 commit。這些 commit 是

  • I 是初始 commit,其中 foo 以「asdf」的內容存在,並且檔案 quux 以「quux」的內容存在。初始 commit 與空樹進行比較,因此 I 是 !TREESAME。

  • A 中,foo 僅包含「foo」。

  • B 包含與 A 相同的變更。其合併 M 是微不足道的,因此對所有父 commit 都是 TREESAME。

  • C 不會變更 foo,但其合併 N 會將其變更為「foobar」,因此對任何父 commit 都不是 TREESAME。

  • Dfoo 設定為「baz」。其合併 OND 的字串組合為「foobarbaz」;也就是說,它對任何父 commit 都不是 TREESAME。

  • Equux 變更為「xyzzy」,而其合併 P 將字串組合為「quux xyzzy」。PO 是 TREESAME,但對 E 不是。

  • X 是一個獨立的根 commit,它新增了一個新檔案 side,而 Y 修改了它。YX 是 TREESAME。其合併 Qside 新增到 P,而 QP 是 TREESAME,但對 Y 不是。

rev-list 會向後追蹤歷史記錄,並根據是否使用了 --full-history 和/或父項重寫(透過 --parents--children)來包含或排除 commit。以下設定可用。

預設模式

如果 commit 對任何父 commit 都不是 TREESAME,則會包含該 commit(儘管這可以變更,請參閱下方的 --sparse)。如果 commit 是合併 commit,且對其中一個父 commit 是 TREESAME,則僅追蹤該父 commit。(即使有多個 TREESAME 父 commit,也只追蹤其中一個。)否則,追蹤所有父 commit。

這導致

	  .-A---N---O
	 /     /   /
	I---------D

請注意,如果有一個可用的 TREESAME 父 commit,則僅追蹤它的規則,已完全將 B 從考量中移除。C 是透過 N 來考量的,但它是 TREESAME。根 commit 會與空樹進行比較,因此 I 是 !TREESAME。

父/子關係僅在 --parents 中可見,但這不會影響預設模式中選取的 commit,因此我們顯示了父 commit 行。

--full-history,不使用父項重寫

此模式與預設模式的不同之處在於:始終追蹤合併 commit 的所有父 commit,即使該合併 commit 對其中一個父 commit 是 TREESAME 也是如此。即使合併 commit 的多個分支都包含已包含的 commit,這並不表示合併 commit 本身已包含!在範例中,我們得到

	I  A  B  N  D  O  P  Q

M 被排除,因為它對兩個父 commit 都是 TREESAME。ECB 都被追蹤,但只有 B 是 !TREESAME,因此其他 commit 不會出現。

請注意,如果不使用父項重寫,則無法真正談論 commit 之間的父/子關係,因此我們顯示它們是斷開連線的。

--full-history,使用父項重寫

只有當一般 commit 是 !TREESAME 時,才會包含它們(儘管這可以變更,請參閱下方的 --sparse)。

始終包含合併 commit。但是,它們的父 commit 清單會被重寫:沿著每個父 commit,修剪掉未包含在內的 commit。這導致

	  .-A---M---N---O---P---Q
	 /     /   /   /   /
	I     B   /   D   /
	 \   /   /   /   /
	  `-------------'

與上面不使用重寫的 --full-history 進行比較。請注意,E 因為它是 TREESAME 而被修剪掉了,但 P 的父 commit 清單被重寫為包含 E 的父 commit ICN,以及 XYQ 也發生了相同的情況。

除了上述設定之外,您還可以變更 TREESAME 是否會影響包含

--dense

如果追蹤的 commit 對任何父 commit 都不是 TREESAME,則會包含該 commit。

--sparse

包含所有追蹤的 commit。

請注意,若沒有使用 --full-history,此選項仍然會簡化合併:若其中一個父節點為 TREESAME,我們只會追蹤該節點,因此不會走訪合併的其他分支。

--simplify-merges

首先,以與使用父節點重寫的 --full-history 相同的方式建立歷史圖 (如上所述)。

然後,根據下列規則,將每個 commit C 簡化為最終歷史記錄中的 C'

  • C' 設定為 C

  • C' 的每個父節點 P 替換為其簡化版本 P'。在此過程中,捨棄其他父節點的祖先,或與空樹 TREESAME 的根 commit,並移除重複項,但請注意,永遠不要捨棄所有與我們 TREESAME 的父節點。

  • 在父節點重寫之後,如果 C' 是根或合併 commit (具有零個或 >1 個父節點)、邊界 commit 或 !TREESAME,則會保留。否則,它會被其唯一的父節點取代。

此選項的效果最好透過與使用父節點重寫的 --full-history 進行比較來展示。範例將變成

	  .-A---M---N---O
	 /     /       /
	I     B       D
	 \   /       /
	  `---------'

請注意 NPQ--full-history 的主要差異

  • N 的父節點清單移除了 I,因為它是另一個父節點 M 的祖先。儘管如此,N 仍然保留,因為它是 !TREESAME。

  • P 的父節點清單也同樣移除了 I。然後 P 被完全移除,因為它只有一個父節點,且為 TREESAME。

  • Q 的父節點清單將 Y 簡化為 X。然後 X 被移除,因為它是 TREESAME 根節點。然後 Q 被完全移除,因為它只有一個父節點,且為 TREESAME。

還有另一種可用的簡化模式

--ancestry-path[=<commit>]

將顯示的 commit 限制為 <commit> 的祖先,或是 <commit> 的後代,或是 <commit> 本身。

作為範例用例,請考慮下列 commit 歷史記錄

	    D---E-------F
	   /     \       \
	  B---C---G---H---I---J
	 /                     \
	A-------K---------------L--M

一般的 *D..M* 會計算出 M 的祖先的 commit 集合,但排除 D 的祖先的 commit。這對於了解自 D 以來導致 M 的歷史記錄中發生了什麼很有用,即「M 有哪些在 D 中不存在的東西」。在此範例中,結果將是除了 AB (以及 D 本身,當然) 之外的所有 commit。

當我們想找出 M 中哪些 commit 因 D 引入的錯誤而受到汙染,並需要修復時,我們可能只想檢視 *D..M* 中實際上是 D 的後代的子集,即排除 CK。這正是 --ancestry-path 選項的作用。應用於 *D..M* 範圍時,會產生

		E-------F
		 \       \
		  G---H---I---J
			       \
				L--M

我們也可以使用 --ancestry-path=D 來取代 --ancestry-path,這在應用於 *D..M* 範圍時表示相同的意思,但只是更明確。

如果我們對此範圍內給定的主題,以及受該主題影響的所有 commit 感興趣,我們可能只想檢視 D..M 中在其祖先路徑中包含該主題的子集。因此,例如,使用 --ancestry-path=H D..M 會產生

		E
		 \
		  G---H---I---J
			       \
				L--M

--ancestry-path=K D..M 會產生

		K---------------L--M

在討論另一個選項 --show-pulls 之前,我們需要建立一個新的範例歷史記錄。

使用者在查看簡化歷史記錄時遇到的常見問題是,他們知道某個 commit 以某種方式變更了檔案,但該 commit 並未出現在檔案的簡化歷史記錄中。讓我們展示一個新的範例,並說明 --full-history--simplify-merges 等選項在這種情況下的作用

	  .-A---M-----C--N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`-Z'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `---Y--'

在此範例中,假設 I 建立 file.txt,該檔案由 ABX 以不同的方式修改。單一父節點 commit CZY 不會變更 file.txt。合併 commit M 是透過解決合併衝突以包含來自 AB 的變更而建立的,因此與兩者都不是 TREESAME。然而,合併 commit R 是透過忽略 Mfile.txt 的內容,並僅採用 Xfile.txt 的內容而建立的。因此,RX 為 TREESAME,但與 M 不是。最後,建立 N 的自然合併解析是採用 Rfile.txt 的內容,因此 NR 為 TREESAME,但與 C 不是。合併 commit OP 與其第一個父節點為 TREESAME,但與其第二個父節點 ZY 不是。

當使用預設模式時,NR 都具有 TREESAME 父節點,因此會走訪這些邊緣,而忽略其他邊緣。產生的歷史圖為

	I---X

當使用 --full-history 時,Git 會走訪每個邊緣。這將會探索 commit AB 以及合併 M,但也會顯示合併 commit OP。使用父節點重寫時,產生的圖為

	  .-A---M--------N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`--'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `------'

在此,合併 commit OP 會貢獻額外的雜訊,因為它們實際上並未對 file.txt 做出變更。它們僅合併了一個基於較舊版本 file.txt 的主題。這是使用許多貢獻者平行工作並將他們的主題分支沿著單一主幹合併的工作流程的存放庫中常見的問題:許多不相關的合併會出現在 --full-history 結果中。

當使用 --simplify-merges 選項時,commit OP 會從結果中消失。這是因為 OP 的重寫第二個父節點可以從其第一個父節點到達。這些邊緣會被移除,然後 commit 看起來像是單一父節點 commit,與其父節點為 TREESAME。這也會發生在 commit N,產生如下的歷史檢視

	  .-A---M--.
	 /     /    \
	I     B      R
	 \   /      /
	  \ /      /
	   `---X--'

在此檢視中,我們會看到來自 ABX 的所有重要單一父節點變更。我們也會看到經過仔細解決的合併 M 和未經過仔細解決的合併 R。這通常足以判斷為什麼 commit AB 在預設檢視中從歷史記錄中「消失」。但是,此方法有一些問題。

第一個問題是效能。與任何先前的選項不同,--simplify-merges 選項需要在傳回單一結果之前走訪整個 commit 歷史記錄。這可能會讓此選項難以用於非常大型的存放庫。

第二個問題是稽核。當許多貢獻者在同一個存放庫上工作時,重要的是哪些合併 commit 將變更引入了重要的分支。上述有問題的合併 R 不太可能是用於合併到重要分支的合併 commit。相反地,合併 N 用於將 RX 合併到重要分支中。此 commit 可能包含有關為什麼變更 X 會在其 commit 訊息中覆寫來自 AB 的變更的資訊。

--show-pulls

除了預設歷史記錄中顯示的 commit 之外,還會顯示每個與其第一個父節點不是 TREESAME 但與後來的父節點為 TREESAME 的合併 commit。

--show-pulls 包含合併 commit 時,該合併會被視為從另一個分支「提取」變更。當在此範例中使用 --show-pulls (且沒有其他選項) 時,產生的圖為

	I---X---R---N

在此,包含合併 commit RN,因為它們分別將 commit XR 提取到基礎分支中。這些合併是 commit AB 未出現在預設歷史記錄中的原因。

--show-pulls--simplify-merges 配對使用時,該圖會包含所有必要的資訊

	  .-A---M--.   N
	 /     /    \ /
	I     B      R
	 \   /      /
	  \ /      /
	   `---X--'

請注意,由於 M 可以從 R 到達,因此從 NM 的邊緣被簡化掉了。但是,N 仍然以重要 commit 的身分出現在歷史記錄中,因為它將變更 R 「提取」到了主要分支中。

--simplify-by-decoration 選項可讓您僅檢視歷史記錄拓撲的整體概況,方法是省略未由標籤參照的 commit。如果 (1) commit 由標籤參照,或 (2) commit 變更了命令列上給定的路徑內容,則會將 commit 標示為 !TREESAME (換句話說,在上述歷史記錄簡化規則後保留)。所有其他 commit 都會標示為 TREESAME (可簡化掉)。

Commit 排序

預設情況下,commit 會以反向時間順序顯示。

--date-order

在顯示所有子節點之前,不要顯示任何父節點,但否則會依 commit 時間戳記順序顯示 commit。

--author-date-order

在顯示所有子節點之前,不要顯示任何父節點,但否則會依作者時間戳記順序顯示 commit。

--topo-order

在顯示所有子節點之前,不要顯示任何父節點,並避免顯示混合在多行歷史記錄上的 commit。

例如,在如下的 commit 歷史記錄中

    ---1----2----4----7
	\	       \
	 3----5----6----8---

其中數字表示 commit 時間戳記的順序,具有 --date-ordergit rev-list 和相關工具會依時間戳記順序顯示 commit:8 7 6 5 4 3 2 1。

使用 --topo-order 時,它們會顯示 8 6 5 3 7 4 2 1 (或 8 7 4 2 6 5 3 1);為了避免顯示來自兩個平行開發軌跡混合在一起的 commit,有些較舊的 commit 會在較新的 commit 之前顯示。

--reverse

以反向順序輸出選擇要顯示的 commit (請參閱上方 Commit 限制章節)。無法與 --walk-reflogs 結合使用。

物件走訪

這些選項主要針對 Git 存放庫的封裝。

--no-walk[=(sorted|unsorted)]

僅顯示給定的 commit,但不走訪其祖先。如果指定了範圍,則此選項無效。如果給定引數 unsorted,則 commit 會依它們在命令列中給定的順序顯示。否則 (如果給定 sorted 或沒有給定引數),則 commit 會依 commit 時間以反向時間順序顯示。無法與 --graph 結合使用。

--do-walk

覆寫先前的 --no-walk

Commit 格式化

--pretty[=<format>]
--format=<format>

以給定的格式美觀地列印 commit 記錄的內容,其中 *<format>* 可以是 *oneline*、*short*、*medium*、*full*、*fuller*、*reference*、*email*、*raw*、*format:<string>* 和 *tformat:<string>* 之一。當 *<format>* 不是上述任何一個,且其中有 *%placeholder* 時,它的行為就像給定 *--pretty=tformat:<format>* 一樣。

請參閱「美觀格式」章節,以取得每個格式的其他詳細資訊。當省略 *=<format>* 部分時,其預設為 *medium*。

注意:您可以在存放庫組態中指定預設的美觀格式 (請參閱 git-config[1])。

--abbrev-commit

不要顯示完整的 40 位元組十六進位 commit 物件名稱,而是顯示唯一命名物件的前置詞。可以使用 "--abbrev=<n>" (如果顯示,也會修改 diff 輸出) 選項來指定前置詞的最小長度。

這應該會讓使用 80 行終端機的人員更容易讀取 "--pretty=oneline"。

--no-abbrev-commit

顯示完整的 40 位元組十六進位提交物件名稱。這會取消 --abbrev-commit,無論是明確指定還是由其他選項(如「--oneline」)暗示。它也會覆蓋 log.abbrevCommit 變數。

--oneline

這是將 "--pretty=oneline --abbrev-commit" 一起使用的簡寫。

--encoding=<encoding>

提交物件在其編碼標頭中記錄用於日誌訊息的字元編碼;此選項可用於告知命令以使用者偏好的編碼重新編碼提交日誌訊息。對於非底層命令,這預設為 UTF-8。請注意,如果物件聲稱以 X 編碼,而我們也以 X 輸出,我們將逐字輸出該物件;這表示原始提交中的無效序列可能會複製到輸出中。同樣地,如果 iconv(3) 無法轉換提交,我們將靜默地逐字輸出原始物件。

--expand-tabs=<n>
--expand-tabs
--no-expand-tabs

在輸出中顯示日誌訊息之前,執行 Tab 擴展(將每個 Tab 替換為足夠的空格,以填滿到下一個顯示列,該顯示列是 *<n>* 的倍數)。 --expand-tabs--expand-tabs=8 的簡寫,而 --no-expand-tabs--expand-tabs=0 的簡寫,它會停用 Tab 擴展。

預設情況下,Tab 會在以 4 個空格縮進日誌訊息的漂亮格式中擴展(即中等,這是預設格式,完整更完整)。

--notes[=<ref>]

在顯示提交日誌訊息時,顯示註解提交的註解(請參閱git-notes[1])。當命令列上未提供 --pretty--format--oneline 選項時,這是 git loggit showgit whatchanged 命令的預設值。

預設情況下,顯示的註解來自 core.notesRefnotes.displayRef 變數中列出的註解 ref(或對應的環境覆寫)。有關詳細資訊,請參閱git-config[1]

使用可選的 *<ref>* 引數,使用該 ref 尋找要顯示的註解。當 ref 以 refs/notes/ 開頭時,可以指定完整的 ref 名稱;當它以 notes/ 開頭時,則會加上 refs/,否則會加上 refs/notes/,以形成 ref 的完整名稱。

可以合併多個 --notes 選項來控制要顯示哪些註解。範例:「--notes=foo」將僅顯示來自「refs/notes/foo」的註解;「--notes=foo --notes」將同時顯示來自「refs/notes/foo」和預設註解 ref 的註解。

--no-notes

不顯示註解。這會藉由重設顯示註解的註解 ref 清單來取消上述的 --notes 選項。選項會依照命令列上給定的順序進行剖析,因此,例如,「--notes --notes=foo --no-notes --notes=bar」將僅顯示來自「refs/notes/bar」的註解。

--show-notes-by-default

除非給定顯示特定註解的選項,否則顯示預設註解。

--show-notes[=<ref>]
--[no-]standard-notes

這些選項已棄用。請改用上述的 --notes/--no-notes 選項。

--show-signature

藉由將簽名傳遞給 gpg --verify 並顯示輸出,來檢查簽署的提交物件的有效性。

--relative-date

--date=relative 的同義詞。

--date=<format>

僅在以人類可讀的格式顯示日期時才生效,例如在使用 --pretty 時。log.date 設定變數會為 log 命令的 --date 選項設定預設值。預設情況下,日期會以原始時區顯示(提交者或作者的時區)。如果將 -local 附加到格式(例如,iso-local),則改為使用使用者的本機時區。

--date=relative 顯示相對於目前時間的日期,例如「2 小時前」。-local 選項對 --date=relative 無效。

--date=local--date=default-local 的別名。

--date=iso(或 --date=iso8601)以類似 ISO 8601 的格式顯示時間戳記。與嚴格的 ISO 8601 格式的差異是

  • 空格而不是 T 日期/時間分隔符號

  • 時間和時區之間的空格

  • 時區的小時和分鐘之間沒有冒號

--date=iso-strict(或 --date=iso8601-strict)以嚴格的 ISO 8601 格式顯示時間戳記。

--date=rfc(或 --date=rfc2822)以 RFC 2822 格式顯示時間戳記,這在電子郵件訊息中很常見。

--date=short 僅顯示日期,而不顯示時間,格式為 YYYY-MM-DD

--date=raw 以自 epoch (1970-01-01 00:00:00 UTC) 以來的秒數顯示日期,後跟一個空格,然後是以與 UTC 的偏移量表示的時區(帶有四位數字的 +-;前兩位是小時,後兩位是分鐘)。也就是說,就像以 strftime("%s %z") 格式化時間戳記一樣。請注意,-local 選項不會影響自 epoch 以來的秒數值(該值始終以 UTC 測量),但會切換隨附的時區值。

如果時區與目前的時區不符,則 --date=human 會顯示時區,如果時區相符,則不會列印整個日期(也就是說,跳過列印「今年」日期的年份,但如果日期是最近幾天,並且我們可以只說出是星期幾,則也會跳過整個日期)。對於較舊的日期,也會省略小時和分鐘。

--date=unix 以 Unix epoch 時間戳記(自 1970 年以來經過的秒數)顯示日期。與 --raw 一樣,這始終是 UTC,因此 -local 無效。

--date=format:... 將格式 ... 提供給您的系統 strftime,但 %s、%z 和 %Z 除外,它們會在內部處理。使用 --date=format:%c 以您的系統地區設定的偏好格式顯示日期。有關格式佔位符的完整清單,請參閱 strftime 手冊。使用 -local 時,正確的語法是 --date=format-local:...

--date=default 是預設格式,並且基於 ctime(3) 輸出。它顯示單行,其中包含三個字母的星期幾、三個字母的月份、日期、時間(格式為「HH:MM:SS」)、後跟 4 位數的年份,以及時區資訊,除非使用本機時區,例如 Thu Jan 1 00:00:00 1970 +0000

--parents

也列印提交的父項(格式為「commit parent…」)。同時啟用父項重寫,請參閱上方的歷史記錄簡化

--children

也列印提交的子項(格式為「commit child…」)。同時啟用父項重寫,請參閱上方的歷史記錄簡化

--left-right

標記提交可從對稱差異的哪一側到達。左側的提交會加上前置字元 <,而右側的提交會加上 >。如果與 --boundary 合併使用,則這些提交會加上前置字元 -

例如,如果您有以下拓撲

	     y---b---b  branch B
	    / \ /
	   /   .
	  /   / \
	 o---x---a---a  branch A

您將會獲得如下輸出

	$ git rev-list --left-right --boundary --pretty=oneline A...B

	>bbbbbbb... 3rd on b
	>bbbbbbb... 2nd on b
	<aaaaaaa... 3rd on a
	<aaaaaaa... 2nd on a
	-yyyyyyy... 1st on b
	-xxxxxxx... 1st on a
--graph

在輸出的左側繪製提交歷史記錄的文字式圖形表示。這可能會導致在提交之間列印額外的行,以使圖形歷史記錄能夠正確繪製。不能與 --no-walk 合併使用。

這會啟用父項重寫,請參閱上方的歷史記錄簡化

這預設會暗示 --topo-order 選項,但也可以指定 --date-order 選項。

--show-linear-break[=<barrier>]

當未使用 --graph 時,所有歷史記錄分支都會被展平,這可能會使您難以看到兩個連續的提交不屬於線性分支。在這種情況下,此選項會在它們之間放置一個分隔符號。如果指定了 <barrier>,則會顯示該字串,而不是預設字串。

漂亮格式

如果提交是合併,並且漂亮格式不是單行電子郵件原始,則會在 Author: 行之前插入額外的一行。此行以「Merge: 」開頭,並列印祖先提交的雜湊值,並以空格分隔。請注意,如果您限制了歷史記錄的視圖,則列出的提交可能不一定是直接父項提交的清單:例如,如果您只對與特定目錄或檔案相關的變更感興趣。

有幾種內建格式,您可以將 pretty.<name> 設定選項設定為其他格式名稱,或format: 字串,來定義其他格式,如下所述(請參閱git-config[1])。以下是內建格式的詳細資訊

  • oneline

    <hash> <title-line>

    這旨在盡可能簡潔。

  • short

    commit <hash>
    Author: <author>
    <title-line>
  • medium

    commit <hash>
    Author: <author>
    Date:   <author-date>
    <title-line>
    <full-commit-message>
  • full

    commit <hash>
    Author: <author>
    Commit: <committer>
    <title-line>
    <full-commit-message>
  • fuller

    commit <hash>
    Author:     <author>
    AuthorDate: <author-date>
    Commit:     <committer>
    CommitDate: <committer-date>
    <title-line>
    <full-commit-message>
  • reference

    <abbrev-hash> (<title-line>, <short-author-date>)

    此格式用於在提交訊息中引用另一個提交,並且與 --pretty='format:%C(auto)%h (%s, %ad)' 相同。預設情況下,日期會以 --date=short 格式化,除非明確指定另一個 --date 選項。與任何帶有格式佔位符的 format: 一樣,它的輸出不會受到其他選項(如 --decorate--walk-reflogs)的影響。

  • email

    From <hash> <date>
    From: <author>
    Date: <author-date>
    Subject: [PATCH] <title-line>
    <full-commit-message>
  • mboxrd

    類似於電子郵件,但是提交訊息中以「From 」開頭的行(前面帶有零個或多個「>」)會以「>」引號,因此它們不會被誤認為是新的提交開始。

  • raw

    原始格式會確切顯示儲存在提交物件中的整個提交。特別是,雜湊值會完整顯示,無論是否使用 --abbrev 或 --no-abbrev,而且父項資訊會顯示真正的父項提交,而不考慮嫁接或歷史記錄簡化。請注意,此格式會影響提交的顯示方式,但不會影響差異的顯示方式,例如 git log --raw。若要在原始差異格式中取得完整的物件名稱,請使用 --no-abbrev

  • format:<format-string>

    format:<format-string> 格式可讓您指定要顯示的資訊。它的運作方式有點像 printf 格式,但值得注意的是,您會使用 %n 而不是 \n 來取得換行符號。

    例如,format:"The author of %h was %an, %ar%nThe title was >>%s<<%n" 會顯示如下內容

    The author of fe6e0ee was Junio C Hamano, 23 hours ago
    The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<

    佔位符為

    • 展開為單個文字字元的佔位符

      %n

      換行符號

      %%

      原始的 %

      %x00

      %x 後面跟著兩個十六進位數字會被替換為一個具有該十六進位數值的位元組(在本文檔的其餘部分中,我們將稱其為「字面格式化程式碼」)。

    • 會影響後續佔位符格式化的佔位符

      %Cred

      將顏色切換為紅色

      %Cgreen

      將顏色切換為綠色

      %Cblue

      將顏色切換為藍色

      %Creset

      重置顏色

      %C(…​)

      顏色規格,如git-config[1]的「設定檔」章節中的「值」下所述。預設情況下,只有在啟用日誌輸出時才會顯示顏色(透過color.diffcolor.ui--color,並且如果我們要前往終端機,則會尊重前者的auto設定)。%C(auto,...) 被接受為預設值的歷史同義詞(例如,%C(auto,red))。指定 %C(always,...) 即使在其他情況下未啟用顏色時也會顯示顏色(儘管請考慮直接使用 --color=always 為整個輸出啟用顏色,包括此格式和 git 可能會著色的任何其他內容)。單獨使用 auto(即 %C(auto))將在下一個佔位符上啟用自動著色,直到顏色再次切換。

      %m

      左 (<)、右 (>) 或邊界 (-) 標記

      %w([<w>[,<i1>[,<i2>]]])

      切換換行,類似於 git-shortlog[1] 的 -w 選項。

      %<( <N> [,trunc|ltrunc|mtrunc])

      使下一個佔位符至少佔用 N 個欄位寬度,如有必要,在右側填充空格。如果輸出長度超過 N 個欄位,則可以選擇在左側 (ltrunc) ..ft、中間 (mtrunc) mi..le 或結尾 (trunc) rig.. 處截斷(使用省略號..)。注意 1:截斷僅在 N >= 2 的情況下才能正確運作。注意 2:N 和 M(見下文)值周圍的空格是可選的。注意 3:表情符號和其他寬字元將佔用兩個顯示欄位,這可能會超出欄位邊界。注意 4:分解的字元組合標記可能會在填充邊界處錯位。

      %<|( <M> )

      使下一個佔位符至少佔用到第 M 個顯示欄位,如有必要,在右側填充空格。對於從終端機視窗右邊緣測量的欄位位置,請使用負 M 值。

      %>( <N> )%>|( <M> )

      分別類似於 %<( <N> )%<|( <M> ),但在左側填充空格

      %>>( <N> )%>>|( <M> )

      分別類似於 %>( <N> )%>|( <M> ),不同之處在於,如果下一個佔位符佔用的空間多於給定的空間,並且其左側有空格,則使用這些空格

      %><( <N> )%><|( <M> )

      分別類似於 %<( <N> )%<|( <M> ),但在兩側填充(即文字置中)

    • 會擴展為從提交中提取的資訊的佔位符

      %H

      提交雜湊值

      %h

      縮寫的提交雜湊值

      %T

      樹狀結構雜湊值

      %t

      縮寫的樹狀結構雜湊值

      %P

      父系雜湊值

      %p

      縮寫的父系雜湊值

      %an

      作者名稱

      %aN

      作者名稱(尊重 .mailmap,請參閱git-shortlog[1]git-blame[1]

      %ae

      作者電子郵件

      %aE

      作者電子郵件(尊重 .mailmap,請參閱git-shortlog[1]git-blame[1]

      %al

      作者電子郵件本地部分(@ 符號之前的部分)

      %aL

      作者本地部分(請參閱 %al)尊重 .mailmap,請參閱git-shortlog[1]git-blame[1]

      %ad

      作者日期(格式尊重 --date= 選項)

      %aD

      作者日期,RFC2822 樣式

      %ar

      作者日期,相對

      %at

      作者日期,UNIX 時間戳記

      %ai

      作者日期,類似 ISO 8601 的格式

      %aI

      作者日期,嚴格的 ISO 8601 格式

      %as

      作者日期,短格式 (YYYY-MM-DD)

      %ah

      作者日期,人性化樣式(類似於git-rev-list[1]--date=human 選項)

      %cn

      提交者名稱

      %cN

      提交者名稱(尊重 .mailmap,請參閱git-shortlog[1]git-blame[1]

      %ce

      提交者電子郵件

      %cE

      提交者電子郵件(尊重 .mailmap,請參閱git-shortlog[1]git-blame[1]

      %cl

      提交者電子郵件本地部分(@ 符號之前的部分)

      %cL

      提交者本地部分(請參閱 %cl)尊重 .mailmap,請參閱git-shortlog[1]git-blame[1]

      %cd

      提交者日期(格式尊重 --date= 選項)

      %cD

      提交者日期,RFC2822 樣式

      %cr

      提交者日期,相對

      %ct

      提交者日期,UNIX 時間戳記

      %ci

      提交者日期,類似 ISO 8601 的格式

      %cI

      提交者日期,嚴格的 ISO 8601 格式

      %cs

      提交者日期,短格式 (YYYY-MM-DD)

      %ch

      提交者日期,人性化樣式(類似於git-rev-list[1]--date=human 選項)

      %d

      參考名稱,類似於 git-log[1] 的 --decorate 選項

      %D

      參考名稱,不包含 " ("、")" 包裝。

      %(decorate[:<options>])

      具有自訂裝飾的參考名稱。decorate 字串後面可以跟著一個冒號和零個或多個以逗號分隔的選項。選項值可以包含字面格式化程式碼。這些必須用於逗號 (%x2C) 和右括號 (%x29),因為它們在選項語法中的作用。

      • prefix=<value>:顯示在參考名稱列表之前。預設值為「(」。

      • suffix=<value>:顯示在參考名稱列表之後。預設值為「)」。

      • separator=<value>:顯示在參考名稱之間。預設值為「, 」。

      • pointer=<value>:顯示在 HEAD 和它指向的分支之間(如果有)。預設值為「-> 」。

      • tag=<value>:顯示在標籤名稱之前。預設值為「tag: 」。

    例如,若要產生不含包裝或標籤註解且以空格作為分隔符號的裝飾

    + %(decorate:prefix=,suffix=,tag=,separator= )

    %(describe[:<options>])

    人類可讀的名稱,類似於git-describe[1];對於無法描述的提交,則為空字串。describe 字串後面可以跟著一個冒號和零個或多個以逗號分隔的選項。當同時新增或移除標籤時,描述可能不一致。

    • tags[=<bool-value>]:不只考慮帶註解的標籤,也考慮輕量標籤。

    • abbrev=<number>:不使用預設的十六進位位數(這會根據儲存庫中的物件數量而變化,預設值為 7),而是使用 <number> 位數,或使用形成唯一物件名稱所需的位數。

    • match=<pattern>:僅考慮符合給定 glob(7) 模式的標籤,不包含 "refs/tags/" 前綴。

    • exclude=<pattern>:不考慮符合給定 glob(7) 模式的標籤,不包含 "refs/tags/" 前綴。

    %S

    在命令列上給定的參考名稱,提交透過該參考名稱到達(如 git log --source),僅適用於 git log

    %e

    編碼

    %s

    主旨

    %f

    經過清理的主旨行,適用於檔案名稱

    %b

    內文

    %B

    原始內文(未換行的主旨和內文)

    %N

    提交註解

    %GG

    來自 GPG 的簽名提交的原始驗證訊息

    %G?

    顯示 "G" 代表好的(有效的)簽名,"B" 代表壞的簽名,"U" 代表有效性不明的好簽名,"X" 代表已過期的好簽名,"Y" 代表由已過期的金鑰所做的簽名,"R" 代表由已撤銷的金鑰所做的簽名,"E" 代表無法檢查簽名(例如,遺失金鑰),而 "N" 代表沒有簽名

    %GS

    顯示已簽署提交的簽署者名稱

    %GK

    顯示用來簽署已簽署提交的金鑰

    %GF

    顯示用來簽署已簽署提交的金鑰指紋

    %GP

    顯示主要金鑰的指紋,該主要金鑰的子金鑰被用來簽署已簽署的提交

    %GT

    顯示用來簽署已簽署提交的金鑰信任等級

    %gD

    reflog 選擇器,例如,refs/stash@{1}refs/stash@{2 minutes ago};格式遵循 -g 選項描述的規則。 @ 前面的部分是命令列上給定的 refname(因此 git log -g refs/heads/master 會產生 refs/heads/master@{0})。

    %gd

    縮短的 reflog 選擇器;與 %gD 相同,但 refname 部分為了人類可讀性而縮短(因此 refs/heads/master 變成僅僅是 master)。

    %gn

    reflog 身分名稱

    %gN

    reflog 身分名稱(尊重 .mailmap,請參閱 git-shortlog[1]git-blame[1]

    %ge

    reflog 身分電子郵件

    %gE

    reflog 身分電子郵件(尊重 .mailmap,請參閱 git-shortlog[1]git-blame[1]

    %gs

    reflog 主題

    %(trailers[:<options>])

    顯示由 git-interpret-trailers[1] 解釋的內文的 trailers。 trailers 字串後面可以加上冒號和零個或多個以逗號分隔的選項。 如果多次提供任何選項,則最後一次出現的選項獲勝。

    • key=<key>:僅顯示具有指定 <key> 的 trailers。 比對不區分大小寫,尾隨的冒號是可選的。 如果多次給定選項,則會顯示符合任何金鑰的 trailer 行。 此選項會自動啟用 only 選項,以便隱藏 trailer 區塊中的非 trailer 行。 如果不希望這樣,可以使用 only=false 停用。 例如,%(trailers:key=Reviewed-by) 顯示金鑰為 Reviewed-by 的 trailer 行。

    • only[=<bool>]:選擇是否應包含來自 trailer 區塊的非 trailer 行。

    • separator=<sep>:指定插入在 trailer 行之間的分隔符號。 預設為換行字元。 字串 <sep> 可以包含上述描述的文字格式化代碼。 若要使用逗號作為分隔符號,則必須使用 %x2C,否則它會被解析為下一個選項。 例如,%(trailers:key=Ticket,separator=%x2C ) 顯示所有金鑰為 "Ticket" 的 trailer 行,並以逗號和空格分隔。

    • unfold[=<bool>]:使其表現得好像給定了 interpret-trailer 的 --unfold 選項。 例如,%(trailers:only,unfold=true) 展開並顯示所有 trailer 行。

    • keyonly[=<bool>]:僅顯示 trailer 的金鑰部分。

    • valueonly[=<bool>]:僅顯示 trailer 的值部分。

    • key_value_separator=<sep>:指定插入在每個 trailer 的金鑰和值之間的分隔符號。 預設為 ": "。 否則,它與上面的 separator=<sep> 具有相同的語意。

注意
某些佔位符可能取決於給定修訂版遍歷引擎的其他選項。 例如,除非我們正在遍歷 reflog 條目(例如,透過 git log -g),否則 %g* reflog 選項會插入空字串。 如果命令列上尚未提供 --decorate,則 %d%D 佔位符將使用「簡短」裝飾格式。

布林選項接受可選值 [=<bool-value>]。 接受的值為 truefalseonoff 等。 請參閱 git-config[1] 中「範例」中的「布林」子章節。 如果給定沒有值的布林選項,則會啟用該選項。

如果在佔位符的 % 之後加入 +(加號),則僅當佔位符展開為非空字串時,才會在展開之前立即插入換行符號。

如果在佔位符的 % 之後加入 -(減號),則僅當佔位符展開為空字串時,才會刪除緊接在展開之前的所有連續換行符號。

如果在佔位符的 % 之後加入 ` ` (空格),則僅當佔位符展開為非空字串時,才會在展開之前立即插入空格。

  • tformat

    tformat: 格式的工作方式與 format: 完全相同,不同之處在於它提供「終結符」語意,而不是「分隔符」語意。 換句話說,每個提交都會附加訊息終結符(通常是換行符號),而不是在條目之間放置分隔符。 這表示單行格式的最後一個條目會像「oneline」格式一樣,正確地以換行符號終止。 例如

    $ git log -2 --pretty=format:%h 4da45bef \
      | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
    4da45be
    7134973 -- NO NEWLINE
    
    $ git log -2 --pretty=tformat:%h 4da45bef \
      | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
    4da45be
    7134973

    此外,任何包含 % 的無法辨識的字串都會被解釋為前面帶有 tformat:。 例如,以下兩個是等效的

    $ git log -2 --pretty=tformat:%h 4da45bef
    $ git log -2 --pretty=%h 4da45bef

差異格式化

預設情況下,git log 不會產生任何差異輸出。 可以使用以下選項來顯示每個提交所做的變更。

請注意,除非明確給定 --diff-merges 變體之一(包括簡短的 -m-c--cc--dd 選項),否則合併提交不會顯示差異,即使選擇了類似 --patch 的差異格式,它們也不會符合類似 -S 的搜尋選項。 例外情況是當使用 --first-parent 時,在這種情況下,first-parent 是合併提交的預設格式。

-p
-u
--patch

產生修補程式(請參閱 使用 -p 產生修補程式文字)。

-s
--no-patch

抑制差異機器的所有輸出。 這對於像 git show 預設顯示修補程式的命令,以抑制其輸出,或取消命令列上較早的選項(如 --patch--stat)的效果非常有用。

-m

以預設格式顯示合併提交的差異。 這類似於 --diff-merges=on,不同之處在於除非也給定 -p,否則 -m 不會產生任何輸出。

-c

為合併提交產生合併差異輸出。 --diff-merges=combined -p 的快捷方式。

--cc

為合併提交產生密集的合併差異輸出。 --diff-merges=dense-combined -p 的快捷方式。

--dd

產生針對合併和一般提交的第一個父項的差異。 --diff-merges=first-parent -p 的快捷方式。

--remerge-diff

為合併提交產生重新合併差異輸出。 --diff-merges=remerge -p 的快捷方式。

--no-diff-merges

--diff-merges=off 的同義詞。

--diff-merges=<format>

指定用於合併提交的差異格式。 預設值為 `off`,除非正在使用 --first-parent,在這種情況下,first-parent 是預設值。

支援以下格式

off, none

停用合併提交差異的輸出。 用於覆蓋隱含值。

on, m

使合併提交的差異輸出以預設格式顯示。 可以使用 log.diffMerges 組態變數來變更預設格式,其預設值為 separate

first-parent, 1

顯示相對於第一個父項的完整差異。 這與 --patch 為非合併提交產生的格式相同。

separate

顯示相對於每個父項的完整差異。 為每個父項產生單獨的日誌條目和差異。

combined, c

同時顯示每個父項與合併結果之間的差異,而不是一次顯示父項與結果之間的成對差異。 此外,它只列出從所有父項修改過的檔案。

dense-combined, cc

透過省略父項中內容只有兩個變體,且合併結果未經修改地選擇其中一個的無趣區塊,進一步壓縮 --diff-merges=combined 產生的輸出。

remerge, r

重新合併雙父項合併提交以建立暫時的樹狀物件—可能包含具有衝突標記之類的檔案。 然後在該暫時樹狀結構和實際的合併提交之間顯示差異。

使用此選項時發出的輸出可能會變更,因此它與其他選項的互動也會變更(除非明確記錄)。

--combined-all-paths

此標誌會使合併差異(用於合併提交)列出所有父項的檔案名稱。 因此,它僅在使用 --diff-merges=[dense-]combined 時有效,並且僅在偵測到檔案名稱變更時才可能有用(即,當要求重新命名或複製偵測時)。

-U<n>
--unified=<n>

產生差異時,使用 <n> 行的上下文,而不是通常的三行。這會隱含 --patch

--output=<file>

輸出到特定的檔案,而不是標準輸出。

--output-indicator-new=<char>
--output-indicator-old=<char>
--output-indicator-context=<char>

指定用於指示產生的 patch 中新、舊或上下文行的字元。通常它們分別是 +- 和 ' '。

--raw

對於每個提交,使用原始 diff 格式顯示變更摘要。請參閱 git-diff[1] 的「原始輸出格式」章節。這與以原始格式顯示日誌本身不同,您可以使用 --format=raw 來實現。

--patch-with-raw

-p --raw 的同義詞。

-t

在 diff 輸出中顯示樹狀物件。

--indent-heuristic

啟用啟發式方法,將 diff hunk 邊界移動,使 patch 更易於閱讀。這是預設值。

--no-indent-heuristic

停用縮排啟發式方法。

--minimal

花費額外的時間來確保產生最小的可能 diff。

--patience

使用 "patience diff" 演算法產生 diff。

--histogram

使用 "histogram diff" 演算法產生 diff。

--anchored=<text>

使用 "anchored diff" 演算法產生 diff。

此選項可以指定多次。

如果一行同時存在於來源和目的地,僅存在一次,並且以這個文字開頭,此演算法會嘗試阻止它在輸出中顯示為刪除或新增。它在內部使用 "patience diff" 演算法。

--diff-algorithm={patience|minimal|histogram|myers}

選擇一個 diff 演算法。變體如下:

default, myers

基本的貪婪 diff 演算法。目前,這是預設值。

minimal

花費額外的時間來確保產生最小的可能 diff。

patience

在產生 patch 時使用 "patience diff" 演算法。

histogram

此演算法將 patience 演算法擴展為「支援低出現率的通用元素」。

例如,如果您將 diff.algorithm 變數設定為非預設值,並想要使用預設值,則必須使用 --diff-algorithm=default 選項。

--stat[=<width>[,<name-width>[,<count>]]]

產生 diffstat。預設情況下,檔名部分將使用盡可能多的空間,其餘部分用於圖表部分。最大寬度預設為終端機寬度,如果未連接到終端機,則為 80 個欄位,並且可以被 <width> 覆寫。檔名部分的寬度可以透過在逗號後給予另一個寬度 <name-width> 或設定 diff.statNameWidth=<width> 來限制。圖表部分的寬度可以使用 --stat-graph-width=<width> 或設定 diff.statGraphWidth=<width> 來限制。使用 --stat--stat-graph-width 會影響所有產生 stat 圖表的命令,而設定 diff.statNameWidthdiff.statGraphWidth 不會影響 git format-patch。透過給定第三個參數 <count>,您可以將輸出限制為前 <count> 行,如果還有更多行,則接著顯示 ...

這些參數也可以使用 --stat-width=<width>--stat-name-width=<name-width>--stat-count=<count> 個別設定。

--compact-summary

在 diffstat 中輸出擴展標頭資訊的精簡摘要,例如檔案建立或刪除(「new」或「gone」,如果它是符號連結,則可選擇「+l」)和模式變更(分別新增或移除可執行位元的「+x」或「-x」)。資訊放在檔名部分和圖表部分之間。這會隱含 --stat

--numstat

類似於 --stat,但以十進制表示法顯示新增和刪除的行數,以及不縮寫的路徑名稱,使其更適合機器讀取。對於二進制檔案,輸出兩個 - 而不是說 0 0

--shortstat

僅輸出 --stat 格式的最後一行,其中包含修改的檔案總數,以及新增和刪除的行數。

-X[<param1,param2,…​>]
--dirstat[=<param1,param2,…​>]

輸出每個子目錄的變更相對量的分佈。 --dirstat 的行為可以透過傳遞逗號分隔的參數列表來自訂。預設值由 diff.dirstat 組態變數控制(請參閱 git-config[1])。可以使用以下參數:

changes

透過計算從來源中刪除或新增到目的地的行數來計算 dirstat 數字。這會忽略檔案內純程式碼移動的數量。換句話說,重新排列檔案中的行不計算為與其他變更一樣多。這是未給定參數時的預設行為。

lines

透過執行常規的基於行的 diff 分析,並將刪除/新增的行數總和來計算 dirstat 數字。(對於二進制檔案,則計算 64 位元組區塊,因為二進制檔案沒有自然的行概念)。這是一種比 changes 行為更昂貴的 --dirstat 行為,但它確實會將檔案內重新排列的行計算為與其他變更一樣多。結果輸出與您從其他 --*stat 選項獲得的結果一致。

files

透過計算變更的檔案數量來計算 dirstat 數字。每個變更的檔案在 dirstat 分析中都佔有相同的權重。這是計算成本最低的 --dirstat 行為,因為它根本不需要查看檔案內容。

cumulative

也計算父目錄中子目錄的變更。請注意,當使用 cumulative 時,報告的百分比總和可能超過 100%。可以使用 noncumulative 參數指定預設(非累計)行為。

<limit>

整數參數指定一個截止百分比(預設為 3%)。變更量低於此百分比的目錄不會顯示在輸出中。

範例:以下程式碼將計算變更的檔案,同時忽略變更檔案總量少於 10% 的目錄,並將子目錄計數累加到父目錄中:--dirstat=files,10,cumulative

--cumulative

--dirstat=cumulative 的同義詞

--dirstat-by-file[=<param1,param2>…​]

--dirstat=files,<param1>,<param2>…​ 的同義詞

--summary

輸出擴展標頭資訊的精簡摘要,例如建立、重新命名和模式變更。

--patch-with-stat

-p --stat 的同義詞。

-z

使用 NUL 而不是換行符號分隔提交。

此外,當給定 --raw--numstat 時,不要修改路徑名稱並使用 NUL 作為輸出欄位終止符。

如果沒有此選項,則具有「不尋常」字元的路徑名稱會按照組態變數 core.quotePath 的說明進行引用(請參閱 git-config[1])。

--name-only

僅顯示後映像樹中每個變更檔案的名稱。檔名通常以 UTF-8 編碼。如需更多資訊,請參閱 git-log[1] 手冊頁中關於編碼的討論。

--name-status

僅顯示每個變更檔案的名稱和狀態。請參閱 --diff-filter 選項的描述,了解狀態字母的含義。就像 --name-only 一樣,檔名通常以 UTF-8 編碼。

--submodule[=<format>]

指定如何顯示子模組中的差異。當指定 --submodule=short 時,使用 _short_ 格式。此格式僅顯示範圍開始和結束時的提交名稱。當指定 --submodule--submodule=log 時,使用 _log_ 格式。此格式列出範圍內的提交,就像 git-submodule[1] summary 所做的一樣。當指定 --submodule=diff 時,使用 _diff_ 格式。此格式顯示提交範圍之間子模組內容變更的內聯 diff。預設為 diff.submodule,如果未設定組態選項,則預設為 _short_ 格式。

--color[=<when>]

顯示彩色 diff。 --color(即沒有 _=<when>_)與 --color=always 相同。 _<when>_ 可以是 alwaysneverauto 之一。

--no-color

關閉彩色 diff。它與 --color=never 相同。

--color-moved[=<mode>]

移動的程式碼行會以不同的顏色顯示。如果未給定選項,則 <mode> 預設為 _no_,如果給定沒有模式的選項,則預設為 _zebra_。模式必須是以下其中之一:

no

移動的行不會被突出顯示。

default

zebra 的同義詞。這可能會在未來變更為更合理的模式。

plain

任何在一處新增,但在另一處被移除的行,將會以 color.diff.newMoved 顏色標示。類似地,color.diff.oldMoved 將會用於標示被移除,但在差異的其他地方新增的行。此模式會偵測任何移動的行,但在審閱時,要判斷一塊程式碼是否在沒有排列組合的情況下被移動,並不是非常有用。

區塊 (blocks)

會貪婪地偵測至少 20 個字母數字字元的移動文字區塊。偵測到的區塊會使用 color.diff.{old,new}Moved 顏色繪製。相鄰的區塊無法區分。

斑馬紋 (zebra)

會如同在 blocks 模式中偵測移動的文字區塊。這些區塊會使用 color.diff.{old,new}Moved 顏色或 color.diff.{old,new}MovedAlternative 顏色繪製。兩種顏色之間的變化表示偵測到新的區塊。

黯淡斑馬紋 (dimmed-zebra)

zebra 類似,但會額外對移動程式碼中不重要的部分進行黯淡處理。兩個相鄰區塊的邊界線被認為是重要的,其餘則是不重要的。dimmed_zebra 是一個已棄用的同義詞。

--no-color-moved

關閉移動偵測。這可用於覆蓋組態設定。它與 --color-moved=no 相同。

--color-moved-ws=<modes>

此設定會配置在使用 --color-moved 執行移動偵測時,如何忽略空白字元。這些模式可以以逗號分隔的列表形式給定。

no

在執行移動偵測時,不要忽略空白字元。

ignore-space-at-eol

忽略行尾 (EOL) 的空白字元變更。

ignore-space-change

忽略空白字元數量的變更。這會忽略行尾的空白字元,並認為所有其他一個或多個空白字元的序列都是等效的。

ignore-all-space

在比較行時忽略空白字元。即使一行有空白字元而另一行沒有,也會忽略差異。

allow-indentation-change

在移動偵測中,最初忽略任何空白字元,然後僅當每行的空白字元變更相同時,才將移動的程式碼區塊分組為一個區塊。這與其他模式不相容。

--no-color-moved-ws

在執行移動偵測時,不要忽略空白字元。這可用於覆蓋組態設定。它與 --color-moved-ws=no 相同。

--word-diff[=<mode>]

顯示單字差異,使用 <mode> 來分隔變更的單字。預設情況下,單字以空白字元分隔;請參閱下面的 --word-diff-regex。<mode> 預設為 plain,且必須是以下其中之一:

color

僅使用顏色來醒目提示變更的單字。隱含 --color

plain

將單字顯示為 [-removed-]{+added+}。如果分隔符號出現在輸入中,則不會嘗試跳脫分隔符號,因此輸出可能會不明確。

porcelain

使用一種特殊的基於行的格式,旨在供腳本使用。新增/移除/未變更的執行會在一般統一差異格式中列印,在行的開頭以 +/-/` ` 字元開始並延伸至行的末尾。輸入中的換行符號以單獨一行上的波浪符號 ~ 表示。

none

再次停用單字差異。

請注意,儘管第一個模式的名稱如此,但如果啟用,則在所有模式中都會使用顏色來醒目提示變更的部分。

--word-diff-regex=<regex>

使用 <regex> 來決定什麼是單字,而不是將非空白字元的執行視為一個單字。也隱含 --word-diff,除非已啟用。

每個不重疊的 <regex> 匹配都被視為一個單字。這些匹配之間的任何內容都被視為空白字元,並且在尋找差異時被忽略 (!)。您可能希望將 |[^[:space:]] 附加到您的正規表示式,以確保它匹配所有非空白字元。包含換行符號的匹配會被靜默地截斷 (!) 在換行符號處。

例如,--word-diff-regex=. 會將每個字元視為一個單字,並相應地逐個字元顯示差異。

也可以透過差異驅動程式或組態選項來設定正規表示式,請參閱 gitattributes[5]git-config[1]。明確給定它會覆蓋任何差異驅動程式或組態設定。差異驅動程式會覆蓋組態設定。

--color-words[=<regex>]

等效於 --word-diff=color 加上 (如果指定了正規表示式) --word-diff-regex=<regex>

--no-renames

關閉重新命名偵測,即使組態檔預設為執行此操作。

--[no-]rename-empty

是否將空 blob 用作重新命名的來源。

--check

如果變更引入衝突標記或空白字元錯誤,則發出警告。什麼被視為空白字元錯誤由 core.whitespace 組態控制。預設情況下,尾隨空白字元(包括僅由空白字元組成的行)以及緊接著行初始縮排內的製表符號的空格字元被視為空白字元錯誤。如果發現問題,則以非零狀態退出。與 --exit-code 不相容。

--ws-error-highlight=<kind>

醒目提示差異的 contextoldnew 行中的空白字元錯誤。多個值以逗號分隔,none 重置先前的值,default 將列表重置為 new,而 allold,new,context 的簡寫。當未指定此選項,並且未設定組態變數 diff.wsErrorHighlight 時,只會醒目提示 new 行中的空白字元錯誤。空白字元錯誤會以 color.diff.whitespace 著色。

--full-index

在產生修補程式格式輸出時,不要顯示開頭的幾個字元,而是在「index」行上顯示完整的前後映像 blob 物件名稱。

--binary

除了 --full-index 之外,還會輸出一個可以使用 git-apply 應用的二進位差異。隱含 --patch

--abbrev[=<n>]

不要在 diff-raw 格式輸出和 diff-tree 標頭行中顯示完整的 40 位元組十六進位物件名稱,而是顯示至少 *<n>* 個十六進位數字長的,可唯一參照該物件的最短字首。在 diff-patch 輸出格式中,--full-index 具有較高的優先順序,也就是說,如果指定了 --full-index,則無論 --abbrev 如何,都會顯示完整的 blob 名稱。可以使用 --abbrev=<n> 指定非預設的位數。

-B[<n>][/<m>]
--break-rewrites[=[<n>][/<m>]]

將完全重寫變更拆分為成對的刪除和建立。這有兩個目的

它會影響將一個相當於完全重寫檔案的變更,視為一系列刪除和插入混合在一起,只有極少數的行恰好在文字上與上下文相符,而不是將其視為完全刪除所有舊內容,然後再插入所有新內容,而數字 m 控制 -B 選項的這個方面 (預設為 60%)。 -B/70% 指定,如果結果中保留的原始內容少於 30%,Git 才會將其視為完全重寫 (也就是說,否則產生的修補程式將會是一系列刪除和插入,並與上下文行混合在一起)。

當與 -M 一起使用時,完全重寫的檔案也會被視為重新命名的來源 (通常 -M 只會將消失的檔案視為重新命名的來源),而數字 n 控制 -B 選項的這個方面 (預設為 50%)。 -B20% 指定,如果與檔案大小相比,新增和刪除的變更佔 20% 或以上,則有資格被選為可能重新命名為另一個檔案的來源。

-M[<n>]
--find-renames[=<n>]

如果產生差異,則為每個提交偵測並報告重新命名。若要在遍歷歷史記錄時追蹤跨重新命名的檔案,請參閱 --follow。如果指定了 n,則它是相似度索引的臨界值(即,與檔案大小相比的新增/刪除量)。例如,-M90% 表示如果檔案的變更少於 90%,Git 應將刪除/新增配對視為重新命名。如果沒有 % 符號,則該數字應讀作分數,其前有一個小數點。也就是說,-M5 變成 0.5,因此與 -M50% 相同。同樣地,-M05-M5% 相同。若要將偵測限制為精確重新命名,請使用 -M100%。預設的相似度索引為 50%。

-C[<n>]
--find-copies[=<n>]

偵測複製以及重新命名。另請參閱 --find-copies-harder。如果指定了 n,則其含義與 -M<n> 相同。

--find-copies-harder

基於效能考量,預設情況下,只有當複製的原始檔案在同一個變更集中被修改時,-C 選項才會尋找複製。此旗標會使命令檢查未修改的檔案,作為複製來源的候選檔案。對於大型專案而言,這是一個非常昂貴的操作,因此請謹慎使用。給定多個 -C 選項具有相同的效果。

-D
--irreversible-delete

省略刪除操作的預影像,也就是說,只印出標頭而不印出預影像與 /dev/null 之間的差異。產生的修補程式並非要用 patchgit apply 來套用;這純粹是為了讓只想專注於審閱變更後文字的人而設。此外,輸出的資訊顯然不足以反向套用這樣的修補程式,即使是手動套用也無法,這也是此選項名稱的由來。

-B 一起使用時,也會省略刪除/建立配對中刪除部分的預影像。

-l<num>

-M-C 選項包含一些初步步驟,可以低成本地偵測重新命名/複製的子集,然後是詳盡的回退部分,它會比較所有剩餘未配對的目的地與所有相關來源。(對於重新命名,只有剩餘未配對的來源是相關的;對於複製,所有原始來源都是相關的。)對於 N 個來源和目的地,此詳盡檢查的複雜度為 O(N^2)。如果涉及的來源/目的地檔案數量超過指定數量,此選項會阻止執行重新命名/複製偵測的詳盡部分。預設為 diff.renameLimit。請注意,值為 0 時會被視為無限制。

--diff-filter=[(A|C|D|M|R|T|U|X|B)…​[*]]

僅選取已新增(A)、複製(C)、刪除(D)、修改(M)、重新命名(R)、類型(即一般檔案、符號連結、子模組等)已變更(T)、未合併(U)、未知(X)或配對已損壞(B)的檔案。可以使用過濾字元的任何組合(包括無)。當 *(全選或全不選)新增到組合中時,如果比較中有任何檔案符合其他條件,則會選取所有路徑;如果沒有檔案符合其他條件,則不會選取任何內容。

此外,這些大寫字母可以轉換為小寫以排除。例如,--diff-filter=ad 會排除新增和刪除的路徑。

請注意,並非所有差異都可以包含所有類型。例如,如果停用這些類型的偵測,則不會出現複製和重新命名的條目。

-S<string>

尋找會變更檔案中指定字串出現次數的差異(即新增/刪除)。適用於腳本編寫者使用。

當您尋找確切的程式碼區塊(例如結構)並想知道該區塊從首次出現以來的歷史記錄時,這非常有用:反覆使用此功能,將預影像中的感興趣區塊回饋到 -S 中,並持續進行直到取得該區塊的最早版本。

也會搜尋二進位檔案。

-G<regex>

尋找修補程式文字包含符合 <regex> 的新增/移除行的差異。

為了說明 -S<regex> --pickaxe-regex-G<regex> 之間的差異,請考慮一個提交,其中同一個檔案中有以下差異

+    return frotz(nitfol, two->ptr, 1, 0);
...
-    hit = frotz(nitfol, mf2.ptr, 1, 0);

雖然 git log -G"frotz\(nitfol" 會顯示此提交,但 git log -S"frotz\(nitfol" --pickaxe-regex 不會(因為該字串的出現次數沒有變更)。

除非提供了 --text,否則將忽略沒有 textconv 過濾器的二進位檔案修補程式。

有關更多資訊,請參閱 gitdiffcore[7] 中的 *pickaxe* 條目。

--find-object=<object-id>

尋找會變更指定物件出現次數的差異。與 -S 類似,只是參數不同,它不會搜尋特定字串,而是搜尋特定物件 ID。

物件可以是 blob 或子模組提交。它暗示 git-log 中的 -t 選項也會尋找樹狀結構。

--pickaxe-all

-S-G 找到變更時,顯示該變更集中所有變更,而不僅僅是包含 <string> 中變更的檔案。

--pickaxe-regex

將提供給 -S 的 <string> 視為要比對的擴充 POSIX 正則表達式。

-O<orderfile>

控制檔案在輸出中出現的順序。這會覆寫 diff.orderFile 設定變數(請參閱 git-config[1])。若要取消 diff.orderFile,請使用 -O/dev/null

輸出順序由 <orderfile> 中 glob 模式的順序決定。所有路徑名稱符合第一個模式的檔案會先輸出,所有路徑名稱符合第二個模式(但不符合第一個模式)的檔案會接著輸出,依此類推。所有路徑名稱都不符合任何模式的檔案會最後輸出,就像檔案末尾有一個隱含的全選模式一樣。如果多個路徑名稱具有相同的等級(它們符合相同的模式但不符合較早的模式),它們相對於彼此的輸出順序是正常順序。

<orderfile> 的剖析方式如下

  • 會忽略空白行,因此它們可以用作分隔符以提高可讀性。

  • 以雜湊符號("#")開頭的行會被忽略,因此它們可以用於註解。如果模式以雜湊符號開頭,請在模式的開頭新增反斜線("\")。

  • 其他每行都包含單個模式。

模式具有與 fnmatch(3) 使用的模式相同的語法和語意,但沒有 FNM_PATHNAME 標誌,除非移除任何數量的最終路徑名稱組件符合模式,否則路徑名稱也符合模式。例如,模式 "foo*bar" 符合 "fooasdfbar" 和 "foo/bar/baz/asdf",但不符合 "foobarx"。

--skip-to=<file>
--rotate-to=<file>

從輸出中捨棄在名為 <file> 之前的檔案(即 *跳到*),或將它們移到輸出的結尾(即 *旋轉到*)。這些選項主要是為了 git difftool 命令而發明,否則可能不是很有用。

-R

交換兩個輸入;也就是說,顯示從索引或磁碟上的檔案到樹狀結構內容的差異。

--relative[=<path>]
--no-relative

從專案的子目錄執行時,可以使用此選項來排除目錄外的變更,並顯示相對於它的路徑名稱。當您不在子目錄中(例如,在裸儲存庫中)時,您可以透過提供 <path> 作為引數,來命名要將輸出設為相對於哪個子目錄。--no-relative 可用於反駁 diff.relative 設定選項和先前的 --relative

-a
--text

將所有檔案視為文字。

--ignore-cr-at-eol

在執行比較時,忽略行尾的回車符號。

--ignore-space-at-eol

忽略行尾 (EOL) 的空白字元變更。

-b
--ignore-space-change

忽略空白字元數量的變更。這會忽略行尾的空白字元,並認為所有其他一個或多個空白字元的序列都是等效的。

-w
--ignore-all-space

在比較行時忽略空白字元。即使一行有空白字元而另一行沒有,也會忽略差異。

--ignore-blank-lines

忽略所有行為空白的變更。

-I<regex>
--ignore-matching-lines=<regex>

忽略所有行都符合 <regex> 的變更。此選項可以指定多次。

--inter-hunk-context=<lines>

顯示差異區塊之間的上下文,最多顯示指定的行數,從而合併彼此靠近的區塊。預設為 diff.interHunkContext,如果未設定設定選項,則為 0。

-W
--function-context

顯示整個函數作為每個變更的上下文行。函數名稱的決定方式與 git diff 計算修補程式區塊標頭的方式相同(請參閱 gitattributes[5] 中的 *定義自訂區塊標頭*)。

--ext-diff

允許執行外部差異輔助程式。如果您使用 gitattributes[5] 設定了外部差異驅動程式,則需要將此選項與 git-log[1] 和相關工具一起使用。

--no-ext-diff

不允許使用外部差異驅動程式。

--textconv
--no-textconv

允許(或不允許)在比較二進位檔案時執行外部文字轉換過濾器。有關詳細資訊,請參閱 gitattributes[5]。由於 textconv 過濾器通常是單向轉換,因此產生的差異適合人類閱讀,但無法套用。因此,預設情況下,textconv 過濾器僅對 git-diff[1]git-log[1] 啟用,而不對 git-format-patch[1] 或差異管道命令啟用。

--ignore-submodules[=<when>]

忽略差異產生中對子模組的變更。<when> 可以是 "none"、"untracked"、"dirty" 或 "all",預設為 "all"。使用 "none" 時,如果子模組包含未追蹤或已修改的檔案,或者其 HEAD 與超級專案中記錄的提交不同,則會將子模組視為已修改,並且可以用來覆寫 git-config[1]gitmodules[5] 中 *ignore* 選項的任何設定。當使用 "untracked" 時,如果子模組僅包含未追蹤的內容,則不會將其視為髒的(但仍會掃描是否有已修改的內容)。使用 "dirty" 時,會忽略對子模組工作樹的所有變更,只會顯示儲存在超級專案中的提交變更(這是 1.7.0 之前的行為)。使用 "all" 時,會隱藏對子模組的所有變更。

--src-prefix=<prefix>

顯示給定的來源前綴,而不是 "a/"。

--dst-prefix=<prefix>

顯示給定的目的地前綴,而不是 "b/"。

--no-prefix

不顯示任何來源或目的地前綴。

--default-prefix

使用預設的來源和目的地前綴("a/" 和 "b/")。這會覆寫設定變數,例如 diff.noprefixdiff.srcPrefixdiff.dstPrefixdiff.mnemonicPrefix(請參閱 git-config(1))。

--line-prefix=<prefix>

在輸出的每一行前面加上額外的前綴。

--ita-invisible-in-index

預設情況下,"git add -N" 新增的條目在 "git diff" 中會顯示為現有的空檔案,在 "git diff --cached" 中會顯示為新檔案。此選項會使條目在 "git diff" 中顯示為新檔案,在 "git diff --cached" 中顯示為不存在的檔案。可以使用 --ita-visible-in-index 還原此選項。這兩個選項都是實驗性的,將來可能會移除。

有關這些常用選項的更詳細說明,另請參閱 gitdiffcore[7]

使用 -p 產生修補程式文字

使用 -p 選項執行 git-diff[1]git-log[1]git-show[1]git-diff-index[1]git-diff-tree[1]git-diff-files[1] 會產生修補程式文字。您可以透過 GIT_EXTERNAL_DIFFGIT_DIFF_OPTS 環境變數(請參閱 git[1])以及 diff 屬性(請參閱 gitattributes[5])自訂修補程式文字的建立。

-p 選項產生的內容與傳統差異格式略有不同

  1. 它前面會有一個 "git diff" 標頭,如下所示

    diff --git a/file1 b/file2

    除非涉及重新命名/複製,否則 a/b/ 檔案名稱相同。 特別是,即使是建立或刪除,也不會使用 /dev/null 來代替 a/b/ 檔案名稱。

    當涉及重新命名/複製時,file1file2 分別顯示重新命名/複製的來源檔案名稱和重新命名/複製產生的檔案名稱。

  2. 接著會有一行或多行的延伸標頭行。

    old mode <mode>
    new mode <mode>
    deleted file mode <mode>
    new file mode <mode>
    copy from <path>
    copy to <path>
    rename from <path>
    rename to <path>
    similarity index <number>
    dissimilarity index <number>
    index <hash>..<hash> <mode>

    檔案模式會以 6 位數的八進位數字列印,包含檔案類型和檔案權限位元。

    延伸標頭中的路徑名稱不包含 a/b/ 前綴。

    相似度索引是不變行的百分比,而相異度索引是已更改行的百分比。 它是一個向下捨入的整數,後跟一個百分比符號。 因此,100% 的相似度索引值保留給兩個相同的檔案,而 100% 的相異度表示舊檔案中沒有任何一行進入新檔案。

    索引行包含變更前後的 blob 物件名稱。 如果檔案模式沒有變更,則會包含 <mode>;否則,會以個別的行顯示舊模式和新模式。

  3. 具有「不尋常」字元的路徑名稱會加上引號,如組態變數 core.quotePath 所述 (請參閱 git-config[1])。

  4. 輸出中所有的 file1 檔案都指提交之前的檔案,而所有的 file2 檔案都指提交之後的檔案。依序將每個變更套用到每個檔案是錯誤的。例如,此修補程式會交換 a 和 b。

    diff --git a/a b/b
    rename from a
    rename to b
    diff --git a/b b/a
    rename from b
    rename to a
  5. Hunk 標頭會提及 hunk 適用於的函式名稱。 如需如何針對特定語言量身打造此標頭的詳細資訊,請參閱 gitattributes[5] 中的「定義自訂 hunk 標頭」。

合併差異格式

任何產生差異的命令都可以使用 -c--cc 選項,在顯示合併時產生合併差異。 當使用 git-diff[1]git-show[1] 顯示合併時,這是預設的格式。 另請注意,您可以為這些命令提供適當的 --diff-merges 選項,以強制產生特定格式的差異。

「合併差異」格式如下所示:

diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
	return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
  }

- static void describe(char *arg)
 -static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
  {
 +	unsigned char sha1[20];
 +	struct commit *cmit;
	struct commit_list *list;
	static int initialized = 0;
	struct commit_name *n;

 +	if (get_sha1(arg, sha1) < 0)
 +		usage(describe_usage);
 +	cmit = lookup_commit_reference(sha1);
 +	if (!cmit)
 +		usage(describe_usage);
 +
	if (!initialized) {
		initialized = 1;
		for_each_ref(get_name);
  1. 它前面會有一個「git diff」標頭,如下所示 (當使用 -c 選項時):

    diff --combined file

    或如下所示 (當使用 --cc 選項時):

    diff --cc file
  2. 接著會有一行或多行的延伸標頭行 (此範例顯示具有兩個父系的合併):

    index <hash>,<hash>..<hash>
    mode <mode>,<mode>..<mode>
    new file mode <mode>
    deleted file mode <mode>,<mode>

    只有當至少有一個 <mode> 與其他 <mode> 不同時,才會出現 mode <mode>,<mode>..<mode> 行。 具有關於偵測到內容移動 (重新命名和複製偵測) 資訊的延伸標頭,是設計用於兩個 <tree-ish> 的差異,而且不會用於合併差異格式。

  3. 接著會有一個兩行的來源檔案/目標檔案標頭:

    --- a/file
    +++ b/file

    與傳統統一差異格式的兩行標頭類似,/dev/null 用於表示建立或刪除的檔案。

    但是,如果提供了 --combined-all-paths 選項,則不會得到兩行的來源檔案/目標檔案,而是會得到 N+1 行的來源檔案/目標檔案標頭,其中 N 是合併提交中的父系數量。

    --- a/file
    --- a/file
    --- a/file
    +++ b/file

    如果啟用重新命名或複製偵測,此延伸格式可能很有用,可讓您查看不同父系中檔案的原始名稱。

  4. Chunk 標頭格式已修改,以防止使用者意外地將它饋送到 patch -p1。 合併差異格式是為了檢閱合併提交變更而建立的,而不是要套用。 此變更類似於延伸的索引標頭中的變更:

    @@@ <from-file-range> <from-file-range> <to-file-range> @@@

    合併差異格式的 chunk 標頭中有 (父系數量 + 1) 個 @ 字元。

與傳統的統一差異格式不同,後者顯示兩個檔案 A 和 B,單一欄具有 - (減號 — 出現在 A 中,但在 B 中移除)、+ (加號 — A 中遺失,但新增至 B) 或 " " (空格 — 未變更) 前綴,此格式會將兩個或多個檔案 file1、file2、... 與一個檔案 X 比較,並顯示 X 與每個 fileN 的差異。 每個 fileN 的一欄會加在輸出行的前面,以註明 X 的行與其差異之處。

欄 N 中的 - 字元表示該行出現在 fileN 中,但未出現在結果中。 欄 N 中的 + 字元表示該行出現在結果中,而 fileN 沒有該行 (換句話說,從該父系的觀點來看,該行已新增)。

在上述範例輸出中,函式簽名從兩個檔案都已變更 (因此,從 file1 和 file2 都移除了兩個 -,再加上 ++ 表示新增的一行沒有出現在 file1 或 file2 中)。 此外,其他八行與 file1 相同,但未出現在 file2 中 (因此以 + 為前綴)。

當由 git diff-tree -c 顯示時,它會將合併提交的父系與合併結果比較 (亦即 file1..fileN 是父系)。 當由 git diff-files -c 顯示時,它會將兩個未解析的合併父系與工作樹檔案比較 (亦即 file1 是階段 2,亦稱為「我們的版本」,file2 是階段 3,亦稱為「他們們的版本」)。

範例

git log --no-merges

顯示整個提交歷史記錄,但跳過任何合併

git log v2.6.12.. include/scsi drivers/scsi

顯示自版本v2.6.12 以來,變更過 include/scsidrivers/scsi 子目錄中任何檔案的所有提交

git log --since="2 weeks ago" -- gitk

顯示過去兩週對檔案 gitk 的變更。 -- 是必要的,以避免與名為 gitk 的**分支**混淆

git log --name-status release..test

顯示位於「test」分支中但尚未位於「release」分支中的提交,以及每個提交修改的路徑清單。

git log --follow builtin/rev-list.c

顯示已變更 builtin/rev-list.c 的提交,包括檔案被賦予現有名稱之前發生的提交。

git log --branches --not --remotes=origin

顯示任何本機分支中但不在 origin 的任何遠端追蹤分支中的所有提交 (您擁有但 origin 沒有的內容)。

git log master --not --remotes=*/master

顯示位於本機 master 中但不在任何遠端存放庫 master 分支中的所有提交。

git log -p -m --first-parent

顯示包含變更差異的歷史記錄,但僅從「主分支」的角度來看,跳過來自合併分支的提交,並顯示合併所引入變更的完整差異。 這僅在遵循嚴格的合併所有主題分支的策略時才有意義。

git log -L '/int main/',/^}/:main.c

顯示檔案 main.c 中函式 main() 隨著時間的推移如何演變。

git log -3

將要顯示的提交數量限制為 3 個。

討論

Git 在某種程度上與字元編碼無關。

  • blob 物件的內容是未經解譯的位元組序列。 核心層級沒有編碼轉換。

  • 路徑名稱以 UTF-8 正規化形式 C 編碼。 這適用於樹狀物件、索引檔案、ref 名稱,以及命令列引數、環境變數和組態檔案中的路徑名稱 (.git/config (請參閱 git-config[1])、gitignore[5]gitattributes[5]gitmodules[5])。

    請注意,Git 在核心層級將路徑名稱簡單地視為非 NUL 位元組的序列,沒有路徑名稱編碼轉換 (Mac 和 Windows 除外)。 因此,即使在使用舊版擴充 ASCII 編碼的平台和檔案系統上,使用非 ASCII 路徑名稱也大多可以運作。 不過,在此類系統上建立的存放庫在以 UTF-8 為基礎的系統 (例如 Linux、Mac、Windows) 上將無法正常運作,反之亦然。 此外,許多以 Git 為基礎的工具只會假設路徑名稱為 UTF-8,而且無法正確顯示其他編碼。

  • 提交記錄訊息通常以 UTF-8 編碼,但也支援其他擴充 ASCII 編碼。 這包括 ISO-8859-x、CP125x 和許多其他編碼,但包括 UTF-16/32、EBCDIC 和 CJK 多位元組編碼 (GBK、Shift-JIS、Big5、EUC-x、CP9xx 等)。

雖然我們鼓勵提交記錄訊息以 UTF-8 編碼,但核心和 Git Porcelain 都設計成不強制專案使用 UTF-8。 如果特定專案的所有參與者發現使用舊版編碼更方便,Git 並不禁止。 不過,有幾件事需要記住。

  1. 如果提交給它的提交記錄訊息看起來不像有效的 UTF-8 字串,則 git commitgit commit-tree 會發出警告,除非您明確說明您的專案使用舊版編碼。 說明這一點的方法是在 .git/config 檔案中有 i18n.commitEncoding,如下所示:

    [i18n]
    	commitEncoding = ISO-8859-1

    使用上述設定建立的提交物件會在它們的 encoding 標頭中記錄 i18n.commitEncoding 的值。 這是為了幫助稍後查看它們的其他人。 如果缺少此標頭,表示提交記錄訊息是以 UTF-8 編碼。

  2. git loggit showgit blame 和相關命令會查看提交物件的 encoding 標頭,並嘗試將記錄訊息重新編碼為 UTF-8,除非另有指定。 您可以在 .git/config 檔案中使用 i18n.logOutputEncoding 指定所需的輸出編碼,如下所示:

    [i18n]
    	logOutputEncoding = ISO-8859-1

    如果您沒有這個組態變數,則會改為使用 i18n.commitEncoding 的值。

請注意,我們刻意選擇不在提交時重新編碼提交記錄訊息以在提交物件層級強制使用 UTF-8,因為重新編碼為 UTF-8 不一定是可逆的操作。

組態

如需核心變數,請參閱 git-config[1],如需與差異產生相關的設定,請參閱 git-diff[1]

format.pretty

--format 選項的預設值。(請參閱上方的美化格式)。預設值為 medium

i18n.logOutputEncoding

顯示記錄時要使用的編碼。(請參閱上方的討論)。如果已設定,預設值為 i18n.commitEncoding 的值,否則為 UTF-8。

本節中此行以上的所有內容都不包含在 git-config[1] 文件中。 以下的內容與該處找到的內容相同:

log.abbrevCommit

如果為 true,則會使 git-log[1]git-show[1]git-whatchanged[1] 假設為 --abbrev-commit。 您可以使用 --no-abbrev-commit 來覆寫此選項。

log.date

設定 log 命令的預設日期時間模式。設定 log.date 的值類似於使用 git log--date 選項。詳情請參閱 git-log[1]

如果格式設定為 "auto:foo" 且正在使用分頁器,則日期格式將使用 "foo" 格式。否則,將使用 "default"。

log.decorate

印出 log 命令顯示的任何 commit 的 ref 名稱。如果指定 short,則不會印出 ref 名稱的前綴 refs/heads/refs/tags/refs/remotes/。如果指定 full,則會印出完整的 ref 名稱(包含前綴)。如果指定 auto,則如果輸出到終端機,則 ref 名稱會如同指定 short 一樣顯示,否則不顯示 ref 名稱。這與 git log--decorate 選項相同。

log.initialDecorationSet

預設情況下,git log 只會顯示某些已知 ref 命名空間的裝飾。如果指定 all,則會將所有 ref 顯示為裝飾。

log.excludeDecoration

從 log 裝飾中排除指定的模式。這類似於 --decorate-refs-exclude 命令列選項,但是可以通過 --decorate-refs 選項覆蓋此設定選項。

log.diffMerges

設定當指定 --diff-merges=on 時要使用的 diff 格式,詳情請參閱 git-log[1] 中的 --diff-merges。預設為 separate

log.follow

如果為 true,則當給定單個 <path> 時,git log 的行為就像使用了 --follow 選項一樣。這與 --follow 有相同的限制,即它不能用於追蹤多個檔案,並且在非線性歷史記錄上效果不佳。

log.graphColors

一個以逗號分隔的顏色列表,可用於在 git log --graph 中繪製歷史線。

log.showRoot

如果為 true,則初始 commit 將顯示為一個大型建立事件。這相當於針對一個空樹的 diff。像 git-log[1]git-whatchanged[1] 這樣的工具通常會隱藏根 commit,現在會顯示它。預設為 True。

log.showSignature

如果為 true,則使 git-log[1]git-show[1]git-whatchanged[1] 假設使用 --show-signature

log.mailmap

如果為 true,則使 git-log[1]git-show[1]git-whatchanged[1] 假設使用 --use-mailmap,否則假設使用 --no-use-mailmap。預設為 True。

notes.mergeStrategy

在解決 notes 衝突時,預設要選擇的合併策略。必須是 manualourstheirsunioncat_sort_uniq 中的一個。預設為 manual。有關每種策略的更多資訊,請參閱 git-notes[1] 的「NOTES MERGE STRATEGIES」部分。

可以通過將 --strategy 選項傳遞給 git-notes[1] 來覆蓋此設定。

notes.<name>.mergeStrategy

在將 notes 合併到 refs/notes/<name> 時,要選擇的合併策略。這會覆蓋更一般的 "notes.mergeStrategy"。有關可用策略的更多資訊,請參閱 git-notes[1] 中的「NOTES MERGE STRATEGIES」部分。

notes.displayRef

除了由 core.notesRefGIT_NOTES_REF 設定的預設集合之外,當使用 git log 命令系列顯示 commit 訊息時,要從中讀取 notes 的 ref(或 ref,如果是一個 glob 或多次指定)。

可以使用 GIT_NOTES_DISPLAY_REF 環境變數來覆蓋此設定,該變數必須是以冒號分隔的 ref 或 glob 列表。

對於不存在的 ref 將會發出警告,但是對於不匹配任何 ref 的 glob 將會被靜默忽略。

可以使用 git log 命令系列的 --no-notes 選項,或這些命令接受的 --notes=<ref> 選項來停用此設定。

"core.notesRef" 的有效值(可能被 GIT_NOTES_REF 覆蓋)也會隱式地添加到要顯示的 ref 列表中。

notes.rewrite.<command>

當使用 <command>(目前為 amendrebase)重寫 commit 時,如果此變數為 false,則 git 不會將 notes 從原始 commit 複製到重寫的 commit。預設為 true。另請參閱下面的 "notes.rewriteRef"。

可以使用 GIT_NOTES_REWRITE_REF 環境變數來覆蓋此設定,該變數必須是以冒號分隔的 ref 或 glob 列表。

notes.rewriteMode

在重寫期間複製 notes 時(請參閱 "notes.rewrite.<command>" 選項),決定如果目標 commit 已有 note 該怎麼做。必須是 overwriteconcatenatecat_sort_uniqignore 中的一個。預設為 concatenate

可以使用 GIT_NOTES_REWRITE_MODE 環境變數來覆蓋此設定。

notes.rewriteRef

在重寫期間複製 notes 時,指定應複製 notes 的(完全限定的)ref。可以是一個 glob,在這種情況下,將複製所有匹配 ref 中的 notes。您也可以多次指定此配置。

沒有預設值;您必須配置此變數才能啟用 note 重寫。將其設定為 refs/notes/commits 以啟用預設 commit notes 的重寫。

可以使用 GIT_NOTES_REWRITE_REF 環境變數覆蓋。有關其格式的更多說明,請參閱上面的 notes.rewrite.<command>

GIT

屬於 git[1] 套件的一部分

scroll-to-top