名稱

git-show  - 顯示各種類型的對象

概要

git show [options] <object>…

描述

顯示一個或多個對象（二進制大型對象、樹、標簽和提交）。

對于提交，它顯示日志消息和文本差異。它還以特殊格式顯示合并提交git diff-tree --cc。

對于標簽，它顯示標簽消息和引用的對象。

對于樹，它顯示名稱（相當于git ls-tree僅限于 - 名稱）。

對于普通的二進制大型對象，它顯示簡單的內容。

該命令使用適用于該git diff-tree命令的選項來控制提交引入的更改的顯示方式。

本手冊頁僅介紹最常用的選項。

選項

<object>…

要顯示的對象的名稱。有關拼寫對象名稱的更完整列表，請參閱 gitrevisions [7]中的“指定修訂”部分。

--pretty=<format>   --format=<format>

在給定的格式漂亮地打?。≒retty-print）提交日志中的內容，在這里<format>可以是一個oneline，short，medium，full，fuller，email，raw，format:<string>和tformat:<string>。當<format>沒有上述情況，并且%placeholder在其中，它的行為就像--pretty=tformat:<format>是給予的一樣。

有關每種格式的其他詳細信息，請參閱“PRETTY FORMATS”部分。當=<format>零件被省略時，它默認為medium。

注意：您可以在存儲庫配置中指定默認的漂亮格式（請參閱 git-config [1]）。

--abbrev-commit

不顯示完整的40字節(jié)十六進制提交對象名稱，只顯示部分前綴。非默認位數可以用“--abbrev = <n>”來指定（如果顯示，它也會修改差異輸出）。

這應該使“--pretty = oneline”對于使用80列終端的人來說更加可讀。

--no-abbrev-commit

顯示完整的40字節(jié)十六進制提交對象名稱。這種否定--abbrev-commit和暗示它的選項如“--oneline”。它也覆蓋log.abbrevCommit變量。

--oneline

這是一起使用的“--pretty = oneline --abbrev-commit”的縮寫。

--encoding=<encoding>

提交對象在其編碼頭中記錄用于日志消息的編碼；這個選項可以用來告訴命令在用戶首選的編碼中重新編寫提交日志消息。對于非管道命令，默認為 UTF-8。請注意，如果一個對象聲稱被編碼X并且正在輸出X，我們將逐字輸出對象; 這意味著原始提交中的無效序列可能會被復制到輸出中。

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

在輸出中顯示日志消息之前，執(zhí)行一個標簽擴展（將每個標簽替換為足夠的空格以填充下一個顯示列的倍數<n>）。--expand-tabs是一種--expand-tabs=8縮寫，并且--no-expand-tabs是一種--expand-tabs=0的縮寫，即禁用選項卡擴展。

默認情況下，突片縮進日志消息擴展在相當格式由4個空格（即medium，這是默認值，full和fuller）。

--notes=<treeish>

在顯示提交日志消息時，顯示注釋提交的注釋（請參閱 git-notes [1]）。這是默認的git log，git show和git whatchanged命令，當沒有--pretty，--format或者--oneline在命令行上給出的選項的時候。

默認情況下，顯示的注釋來自core.notesRef和notes.displayRef變量（或相應的環(huán)境覆蓋）中列出的注釋 ref 。有關更多詳細信息，請參閱 git-config [1]。

使用可選<treeish>參數，使用樹狀圖來查找要顯示的注釋。當它開始時，樹木可以指定完整的 refname refs/notes/； 當它開始時notes/，refs/亦或是refs/notes/以前綴形成 ref 的全名。

多個 - 注釋選項可以結合使用來控制顯示哪些筆記。例如：“--notes = foo”將只顯示“refs / notes / foo”中的注釋; “--notes = foo --notes”將顯示來自“refs / notes / foo”和默認注釋 ref（s）的兩個注釋。

--no-notes

不要顯示注釋。這會取消上述--notes選項，方法是重置從中顯示注釋的注釋列表。選項按照命令行給出的順序進行解析，因此，例如“--notes --notes = foo --no-notes --notes = bar”將僅顯示“refs / notes / bar”中的注釋。

--show-notes=<treeish>   --no-standard-notes

這些選項已被棄用。改為使用上面的 - 注釋/  - 無備注選項。

--show-signature

通過簽名傳遞gpg --verify并顯示輸出來檢查簽名提交對象的有效性。

漂亮的格式（Pretty formats）

如果提交是合并，并且不是美觀格式oneline，email或者raw在該Author:行之前插入了一條附加線。該行以“Merge：”開始，并且祖先提交的sha1被打印出來，用空格分隔。請注意，如果您限制了對歷史的查看，列出的提交可能不一定是直接父輩提交的列表：例如，如果您只對與某個目錄或文件相關的更改感興趣。

有幾種內置格式，你可以通過設置一個漂亮的<name> config選項來定義其他格式format:，如下所述（參見 git-config [1]）。以下是內置格式的詳細信息：

• oneline   <sha1> <標題行>設計得盡可能緊湊。

• short

commit <sha1> Author: <author>

<title line>

• mediumcommit <sha1> Author: <author> Date:   <author date><title line><full commit message>

• full

commit <sha1> Author: <author> Commit: <committer>

<title line>

<full commit message>

• fullercommit <sha1> Author:     <author> AuthorDate: <author date> Commit:     <committer> CommitDate: <committer date><title line><full commit message>

• email

From <sha1> <date> From: <author> Date: <author date> Subject: PATCH <title line>

<full commit message>

• raw                                                                                                   raw格式示出了整個提交完全一樣存儲在 commit 對象。值得注意的是，無論使用--abbrev 還是--no-abbrev，SHA-1 都會全部顯示，并且parents信息會顯示真正的父提交，而不會考慮移植或簡化歷史記錄。請注意，這種格式會影響提交顯示的方式，但不會影響比較顯示的方式git log --raw。要以原始差異格式獲取完整對象名稱，請使用--no-abbrev。

• format:<string>

format:<string>格式允許您指定要顯示的信息。它的工作原理與 printf 格式有點相似，但有一個值得注意的例外，那就是你使用的是換行符%n而不是\n。

例如，format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"會顯示這樣的事情：

fe6e0ee 的作者 是Junio C Hamano，23小時前標題是>> t4119：test autocomputing -p <n>用于傳統(tǒng)差異輸入。<<

占位符是：

-  `%H`: commit hash-  `%h`: abbreviated commit hash

-  `%T`: tree hash-  `%t`: abbreviated tree hash

-  `%P`: parent hashes-  `%p`: abbreviated parent hashes

-  `%an`: author name-  `%aN`: author name (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%ae`: author email-  `%aE`: author email (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%ad`: author date (format respects --date= option)-  `%aD`: author date, RFC2822 style

-  `%ar`: author date, relative-  `%at`: author date, UNIX timestamp

-  `%ai`: author date, ISO 8601-like format-  `%aI`: author date, strict ISO 8601 format

-  `%cn`: committer name-  `%cN`: committer name (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%ce`: committer email-  `%cE`: committer email (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%cd`: committer date (format respects --date= option)-  `%cD`: committer date, RFC2822 style

-  `%cr`: committer date, relative-  `%ct`: committer date, UNIX timestamp

-  `%ci`: committer date, ISO 8601-like format-  `%cI`: committer date, strict ISO 8601 format

-  `%d`: ref names, like the --decorate option of [git-log[1]](git-log)-  `%D`: ref names without the " (", ")" wrapping.

-  `%e`: encoding-  `%s`: subject

-  `%f`: sanitized subject line, suitable for a filename-  `%b`: body

-  `%B`: raw body (unwrapped subject and body)-  `%N`: commit notes

-  `%GG`: raw verification message from GPG for a signed commit-  `%G?`: show "G" for a good (valid) signature, "B" for a bad signature, "U" for a good signature with unknown validity, "X" for a good signature that has expired, "Y" for a good signature made by an expired key, "R" for a good signature made by a revoked key, "E" if the signature cannot be checked (e.g. missing key) and "N" for no signature

-  `%GS`: show the name of the signer for a signed commit-  `%GK`: show the key used to sign a signed commit

-  `%gD`: reflog selector, e.g., `refs/stash@{1}` or `refs/stash@{2 minutes ago`}; the format follows the rules described for the `-g` option. The portion before the `@` is the refname as given on the command line (so `git log -g refs/heads/master` would yield `refs/heads/master@{0}`).-  `%gd`: shortened reflog selector; same as `%gD`, but the refname portion is shortened for human readability (so `refs/heads/master` becomes just `master`).

-  `%gn`: reflog identity name-  `%gN`: reflog identity name (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%ge`: reflog identity email-  `%gE`: reflog identity email (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%gs`: reflog subject-  `%Cred`: switch color to red

-  `%Cgreen`: switch color to green-  `%Cblue`: switch color to blue

-  `%Creset`: reset color-  `%C(…)`: color specification, as described under Values in the "CONFIGURATION FILE" section of [git-config[1]](git-config). By default, colors are shown only when enabled for log output (by `color.diff`, `color.ui`, or `--color`, and respecting the `auto` settings of the former if we are going to a terminal). `%C(auto,...)` is accepted as a historical synonym for the default (e.g., `%C(auto,red)`). Specifying `%C(always,...) will show the colors even when color is not otherwise enabled (though consider just using `--color=always` to enable color for the whole output, including this format and anything else git might color). `auto` alone (i.e. `%C(auto)`) will turn on auto coloring on the next placeholders until the color is switched again.

-  `%m`: left (`<`), right (`>`) or boundary (`-`) mark-  `%n`: newline

-  `%%`: a raw `%`-  `%x00`: print a byte from a hex code

-  `%w([<w>[,<i1>[,<i2>]]])`: switch line wrapping, like the -w option of [git-shortlog[1]](git-shortlog).-  `%<(<N>[,trunc|ltrunc|mtrunc])`: make the next placeholder take at least N columns, padding spaces on the right if necessary. Optionally truncate at the beginning (ltrunc), the middle (mtrunc) or the end (trunc) if the output is longer than N columns. Note that truncating only works correctly with N >= 2.

-  `%<|(<N>)`: make the next placeholder take at least until Nth columns, padding spaces on the right if necessary-  `%>(<N>)`, `%>|(<N>)`: similar to `%<(<N>)`, `%<|(<N>)` respectively, but padding spaces on the left

-  `%>>(<N>)`, `%>>|(<N>)`: similar to `%>(<N>)`, `%>|(<N>)` respectively, except that if the next placeholder takes more spaces than given and there are spaces on its left, use those spaces-  `%><(<N>)`, `%><|(<N>)`: similar to `% <(<N>)`, `%<|(<N>)` respectively, but padding both sides (i.e. the text is centered)

-  %(trailers): display the trailers of the body as interpreted by [git-interpret-trailers[1]](git-interpret-trailers)NoteSome placeholders may depend on other options given to the revision traversal engine. For example, the %g* reflog options will insert an empty string unless we are traversing reflog entries (e.g., by git log -g). The %d and %D placeholders will use the "short" decoration format if --decorate was not already provided on the command line.If you add a + (plus sign) after % of a placeholder, a line-feed is inserted immediately before the expansion if and only if the placeholder expands to a non-empty string.If you add a - (minus sign) after % of a placeholder, all consecutive line-feeds immediately preceding the expansion are deleted if and only if the placeholder expands to an empty string.If you add a  (space) after % of a placeholder, a space is inserted immediately before the expansion if and only if the placeholder expands to a non-empty string.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

常見的差異選項

-p   -u   --patch

生成補?。ㄕ垍㈤喩裳a丁一節(jié)）。

-s   --no-patch

抑制差異輸出。對于像git show這樣的命令很有用，默認顯示補丁，或者取消效果--patch。

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

使用<n>行上下文生成差異，而不是通常的三行。意味著-p。

--raw

對于每個提交，使用原始 diff格 式顯示更改的摘要。請參閱 git-diff [1]的“RAW OUTPUT FORMAT”部分。這與以原始格式顯示日志本身不同，您可以使用它--format=raw。

--patch-with-raw

-p --raw的同義詞。

--indent-heuristic   --no-indent-heuristic

這些是為了幫助調試和調整實驗啟發(fā)式（默認情況下是關閉的），這些啟發(fā)式技術改變了差異邊界以使修補程序更易于閱讀。

--minimal

花費額外的時間來確保生成最小可能的差異。

--patience

使用“耐心差異”算法生成差異。

--histogram

使用“直方圖差異”算法生成差異。

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

選擇一種差異算法。變體如下：

default, myers

基本的貪婪的 diff 算法。目前，這是默認設置。

minimal

花費額外的時間來確保生成最小可能的差異。

patience

生成補丁時使用“耐心差異”算法。

histogram

該算法將耐心算法擴展為“支持低出現率的通用元素”。

例如，如果將 diff.algorithm 變量配置為非默認值并希望使用默認值，則必須使用--diff-algorithm=default選項。

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

生成一個 diffstat。默認情況下，文件名部分使用盡可能多的空間，其余部分使用圖形部分。最大寬度默認為終端寬度，如果未連接到終端，則最大寬度為80列，并且可以被覆蓋<width>。文件名部分的寬度可以通過<name-width>逗號后面的另一個寬度來限制。圖形部分的寬度可以通過使用--stat-graph-width=<width>（影響所有生成統(tǒng)計圖的命令）或通過設置diff.statGraphWidth=<width>（不影響git format-patch）來限制。通過給出第三個參數<count>，可以將輸出限制在第一<count>行，緊接著...（如果還有更多的話）。

這些參數也可以單獨設置--stat-width=<width>，--stat-name-width=<name-width>和--stat-count=<count>。

--numstat

類似于--stat，但顯示十進制表示法中添加和刪除的行數以及不帶縮寫的路徑名，以使其更加機器友好。對于二進制文件，輸出兩個-而不是說0 0。

--shortstat

只輸出包含修改文件總數的格式--stat的最后一行，以及添加和刪除行的數量。

--dirstat=<param1,param2,…>

輸出每個子目錄的相對變化量分布?？梢酝ㄟ^傳遞一個用逗號分隔的參數列表來定制--dirstat行為。默認值由diff.dirstat配置變量控制（請參 閱git-config [1]）。以下參數可用：

changes

通過計算已從源中刪除或添加到目標的行來計算 dirstat 數字。這會忽略文件中純代碼移動的數量。換句話說，重新排列文件中的行數不會與其他更改一樣多。這是沒有給出參數時的默認行為。

lines

通過執(zhí)行常規(guī)基于行的差異分析來計算 dirstat 數字，并且將移除/添加的行數相加。（對于二進制文件，取而代之的是計算64字節(jié)的塊，因為二進制文件沒有自然的行概念）。這是一種--dirstat比changes行為更為昂貴的行為，但它可以像其他更改一樣對文件中的重新排列的行進行計數。結果輸出與您從其他--*stat選項中獲得的結果一致。

files

通過計算更改的文件數量來計算 dirstat 數字。在dirstat 分析中每個更改的文件都相同。這是計算上最便宜的--dirstat行為，因為它根本不需要查看文件內容。

cumulative

計數父目錄的子目錄中的更改。請注意，使用時cumulative，報告的百分比總和可能超過100％。默認（非累積）行為可以用noncumulative參數指定。

<limit>

整數參數指定截斷百分比（默認為3％）。輸出中不顯示貢獻小于此百分比的目錄。

示例：以下內容將計數已更改的文件，同時忽略占已更改文件總數少于10％的目錄，并累積父目錄中的子目錄計數：--dirstat=files,10,cumulative。

--summary

輸出擴展頭信息的精簡摘要，如創(chuàng)建、重命名和模式更改。

--patch-with-stat

-p --stat=的同義詞。

-z

用 NUL 分開提交，而不用新的換行符。

此外，當--raw或--numstat已經被給出的時候，請勿使用路徑名并將 NUL 用作輸出字段終止符。

如果沒有這個選項，帶有“不尋?！弊址穆窂矫麑凑张渲米兞?code>core.quotePath的說明引用（請參閱 git-config [1]）。

--name-only

僅顯示已更改文件的名稱。

--name-status

僅顯示已更改文件的名稱和狀態(tài)。有關--diff-filter狀態(tài)字母的含義，請參閱選項說明。

--submodule=<format>

指定如何顯示子模塊中的差異。指定使用--submodule=short的short格式時。這種格式只顯示范圍開始和結束處的提交名稱。當--submodule或者--submodule=log被指定時，使用log格式。這種格式列出了像 git-submodule [1] summary那樣的提交。當--submodule=diff指定時，使用diff格式。這種格式顯示了提交范圍內子模塊內容變化的內聯比較。如果配置選項未設置，則默認為diff.submodule或short格式。

--color=<when>

顯示有色差異。--color（即沒有=<when>）是一樣的--color=always。<when>可以是一個always，never或auto。

--no-color

關閉有色差異。它和--color=never。一樣。

--word-diff=<mode>

顯示一個單詞diff，使用<mode>分隔已更改的單詞。默認情況下，單詞由空格分隔; 見--word-diff-regex下文。<mode>默認為plain，并且必須是以下之一：

color

僅使用顏色突出顯示更改的詞。意味著--color。

plain

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

porcelain

使用專門用于腳本消費量的基于行的格式。以通常的統(tǒng)一差異格式打印已添加/已刪除/未更改的運行，以行開始處的+/ -/字符開始并延伸至行尾。輸入中~的換行符通過它自己的一行代字符表示。

none

再次禁用字差異。

請注意，盡管第一個模式的名稱，如果啟用，顏色將用于突出顯示所有模式中更改的部分。

--word-diff-regex=<regex>

使用<regex>來決定一個單詞是什么，而不是將非空白的運行視為一個單詞。也意味著--word-diff除非已經啟用。

每個<regex>的非重疊匹配都被視為一個單詞。為了找到差異，這些匹配之間的任何內容都被認為是空白并被忽略(!) 。你可能想追加|[^[:space:]]到你的正則表達式，以確保它匹配所有非空白字符。包含換行符的匹配在換行符處被無提地截斷(!)。

例如，--word-diff-regex=.將每個字符看作單詞，并相應地逐個字符地顯示差異。

正則表達式也可以通過 diff 驅動程序或配置選項來設置，請參閱 gitattributes [5]或git-config [1]。顯式給予它將覆蓋任何 diff 驅動程序或配置設置。差異驅動程序覆蓋配置設置

--color-words=<regex>

相當于--word-diff=color加（如果指定了正則表達式）--word-diff-regex=<regex>。

--no-renames

關閉重命名檢測，即使配置文件提供了默認設置。

--check

警告如果更改引入沖突標記或空白錯誤。認為空白錯誤是由core.whitespace配置控制的。默認情況下，尾隨空格（包括單獨由空格組成的行）和空格字符（緊跟該行的初始縮進內的制表符后面的空格字符）將被視為空白錯誤。如果發(fā)現問題，則退出非零狀態(tài)。與--exit-code 不兼容。

--ws-error-highlight=<kind>

在context、old或new差異線中突出顯示空白的錯誤。多個值以逗號分隔，none重置以前的值，default將列表重置為new和all簡寫為old,new,context。如果未給出此選項，并且diff.wsErrorHighlight未設置配置變量，則只會突出顯示new行中的空白錯誤。空白錯誤是彩色的color.diff.whitespace。

--full-index

在生成補丁格式輸出時，在“索引”行上顯示完整的映像前和映像后blob對象名稱，而不是第一批字符。

--binary

除了--full-index，輸出一個可以應用git-apply的二進制差異。

--abbrev=<n>

代替在 diff-raw 格式輸出和 diff-tree 標題行中顯示完整的40字節(jié)十六進制對象名稱，只顯示部分前綴。這與--full-index上面的選項無關，后者控制 diff-patch輸出格式。非默認的位數可以用指定--abbrev=<n>。

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

將完全重寫更改分解為刪除和創(chuàng)建對。這有兩個目的：

它影響到一種改變的方式，這種改變相當于整個文件的重寫，而不是像一系列刪除和插入混合在一起，只有幾行文字與上下文相匹配，而是作為舊的一切的一次刪除，單次插入所有新事物，并且數字m控制-B 選項的這個方面（默認為60％）。-B/70%指定只有少于30％的原始數據應保留在 Git 的結果中，以便將其視為全部重寫（否則結果補丁將是一系列與上下文行混合的刪除和插入）。

與-M 一起使用時，完全重寫的文件也被認為是重命名的來源（通常-M僅考慮作為重命名源消失的文件），并且該數字n控制著-B 選項的這個方面（默認為50％）。-B20%指定添加和刪除相對于文件大小的20％或更多的更改有資格作為可能的重命名源到另一個文件。

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

如果生成差異，則檢測并報告每次提交的重命名。在遍歷歷史記錄時跨越重命名后續(xù)文件，請參閱--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。由此產生的補丁不適用于patch或git apply; 這僅適用于那些想專注于更改后查看文本的人。另外，輸出顯然缺乏足夠的信息來反向應用這樣的補丁，甚至是手動的，因此也就是選項的名稱。

在與-B刪除/創(chuàng)建對的刪除部分一起使用時，還要省略原圖。

-l<num>

在-M和-C選項需要為 O（n ^ 2）的處理時間，其中 n 是/復制目標潛在的重命名的數目。如果重命名/復制目標的數量超過指定的數量，則此選項可防止重命名/復制檢測運行。

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

只選擇已添加（A），已復制（C），已刪除（），已D修改（M），已重命名（R），其類型（即常規(guī)文件，符號鏈接，子模塊，...）已更改（T），已取消合并（U）未知（X）或已配對的被破壞的（B）?？梢允褂萌魏芜^濾字符的組合（包括無）。當*（全部或無）添加到組合中時，如果有任何文件與比較中的其他條件匹配，則選擇所有路徑; 如果沒有與其他標準匹配的文件，則不會選擇任何內容。

此外，這些大寫字母可以降低排除。例如--diff-filter=ad排除添加和刪除的路徑。

-S<string>

查找改變文件中指定字符串出現次數（即添加/刪除）的差異。旨在供腳本編寫者的使用。

當你尋找一個精確的代碼塊（比如一個結構體）并且想要知道該塊自第一次出現以來的歷史記錄時，它非常有用：迭代地使用該特征將原始圖像中的有趣塊返回到-S，并繼續(xù)前進，直到獲得該塊的第一個版本。

-G<regex>

尋找補丁文本包含與<regex>匹配的添加/刪除行的差異。

為了說明之間-S<regex> --pickaxe-regex和-G<regex>的區(qū)別，考慮在同一個文件中的以下 DIFF 提交：

+    return !regexec(regexp, two->ptr, 1, &regmatch, 0);...-    hit = !regexec(regexp, mf2.ptr, 1, &regmatch, 0);

雖然git log -G"regexec\(regexp"會顯示此提交，但git log -S"regexec\(regexp" --pickaxe-regex不會（因為該字符串的出現次數沒有改變）。

有關pickaxe更多信息，請參閱 gitdiffcore [7]中的條目。

--pickaxe-all

當-S或-G發(fā)現更改時，顯示該更改集中的所有更改，而不僅僅是包含<string>中的更改的文件。

--pickaxe-regex

將給定-S的<string> 視為擴展的 POSIX 正則表達式進行匹配。

-O<orderfile>

控制文件在輸出中出現的順序。這覆蓋了diff.orderFile配置變量（請參閱 git-config [1]）。取消diff.orderFile，使用-O/dev/null。

輸出順序由<orderfile>中的全局模式順序決定。所有具有與第一個模式相匹配的路徑名的文件將首先輸出，接下來將輸出所有具有匹配第二個模式（但不是第一個）的路徑名的文件，依此類推。最后輸出所有不匹配任何模式的路徑名的文件，就好像文件末尾有一個隱含的匹配模式一樣。如果多個路徑名具有相同的排名（它們匹配相同的模式但沒有更早的模式），則它們的輸出順序相對于彼此是正常順序。

按以下方式解析<orderfile>：

• 空白行被忽略，所以它們可以用作分隔符以提高可讀性。

• 以散列（“ #”）開頭的行會被忽略，因此它們可以用于注釋。如果以散列開頭，則在模式的開頭添加反斜杠（“ \”）。

• 每個其他行都包含一個 pattern.atterns 與沒有 FNM_PATHNAME 標志的 fnmantch（3）使用的模式具有相同的語法和語義，除非路徑名也匹配模式，如果刪除任何數量的最終路徑名組件都與該模式匹配。例如，模式“ foo*bar”匹配“ fooasdfbar”和“ foo/bar/baz/asdf”但不是“foobarx即使一行有空白，而另一行沒有空白，這也會忽略差異。--ignore-blank-lines忽略其行全部空白的更改。--inter-hunk-context = <lines>在 diff hunk 之間顯示上下文，直到指定的行數，從而融合彼此接近的hunk。默認為diff.interHunkContext如果配置選項未設置，則為0。-W --function-context 顯示更改的整個周圍功能。--ext-diff 允許執(zhí)行一個外部diff助手。如果你用 gitattributes [5]設置外部差異驅動程序，你需要在 git-log [1]和朋友中使用這個選項。--no-ext-diff 禁止外部 diff 驅動程序。--textconv --no-textconv 允許（或不允許）在比較二進制文件時運行外部文本轉換過濾器。有關詳細信息，請參閱gitattributes [5]。由于 textconv過濾器通常是單向轉換，因此生成的差異適合人類消費，但無法應用。出于這個原因，默認情況下，textconv 過濾器僅針對 git-diff [1]和 git-log [1]啟用，但不適用于 git-format-patch [1]或 diff plumbing命令。 - 忽略子模塊= <時> 忽略差異代中子模塊的更改。<when>可以是“none”，“untracked”，“dirty”或“all”，這是默認設置。如果子模塊包含未跟蹤或已修改的文件，或者HEAD與超級項目中記錄的提交不同，并且可用于覆蓋ignore選項在 git-config [1]或 gitmodules [5]中。當使用“未跟蹤”時，如果子模塊僅包含未跟蹤內容（但仍然針對修改內容進行掃描），則子模塊不會被視為臟。使用“dirty”會忽略對子模塊工作樹的所有更改，只會顯示超級項目中存儲的提交更改（這是1.7.0之前的行為）。使用“all”隱藏對子模塊的所有更改。--src-prefix = <prefix>顯示給定的源前綴而不是“a /”。--dst-prefix = <prefix>顯示給定的目標前綴而不是“b /”。--no-prefix不顯示任何源或目標前綴。--line-prefix = <prefix>為每行輸出添加一個附加前綴。--ita -in-in-index默認條目由“git add -N”添加 在“git diff”中顯示為現有的空文件，在“git diff --cached”中顯示為新文件。這個選項使條目在“git diff”中顯示為新文件，在“git diff --cached”中不存在。這個選項可以恢復--ita-visible-in-index。這兩個選項都是實驗性的，可以在將來刪除。有關這些常用選項的更多詳細說明，另請參閱gitdiffcore [7]。使用-p生成補丁當“git-diff-index”，“git-diff-tree”或“ git-diff-files“是用一個-p選項運行的，”git diff“沒有--raw選項，或者”git log“用”-p“選項運行，它們不會產生上面描述的輸出; 相反，他們生成一個補丁文件。您可以通過GIT_EXTERNAL_DIFF和GIT_DIFF_OPTS環(huán)境變量自定義這些修補程序的創(chuàng)建。-p選項生成的內容與傳統(tǒng)的 diff 格式略有不同：

• 它前面有一個“git diff”header，看起來像這樣：

diff --git a/file1 b/file2

在a/和b/文件名是，除非重命名/副本所涉及的相同。尤其是，即使是創(chuàng)建或刪除，/dev/null也可not用于替換文件名a/或b/文件名。

當重命名/復制參與，file1并file2示出了重命名/復制的源文件的名稱和重命名/復制分別產生，該文件的名稱。

1. 它后跟一個或多個擴展標題行：舊模式<mode>新模式<mode>已刪除文件模式<mode>新文件模式<mode>從<path>復制到<path>從<path>重命名重命名為<path>相似索引<number>不相似索引<number>索引<hash> .. <hash> <mode>文件模式打印為6位八進制數字，包括文件類型和文件權限位。擴展頭中的路徑名不包含a/和b/前綴。相似性指數是未改變的行的百分比，不相似性指數是改變的行的百分比。它是一個向下舍入的整數，后面跟著一個百分號。100％的相似性指數值因此保留給兩個相同的文件，而100％相異性意味著來自舊文件的任何行都不會將其轉換為新的文件。索引行包含更改前后的 SHA-1校驗和。如果文件模式沒有改變，則包含<mode>; 否則，單獨的行表示舊模式和新模式。

帶有“不常用”字符的路徑名將按照配置變量的說明引用core.quotePath（請參閱 git-config [1]）。

file1輸出中的所有文件在提交之前引用文件，所有file2文件在提交之后引用文件。將每個更改順序應用于每個文件是不正確的。例如，這個補丁會將 a 和 b ：diff --git a / ab / b 重命名為 a 重命名為 b diff --git a / bb / a 重命名為 b 重命名為 aCombined diff formatAny diff-generating 命令可以將-c或者顯示合并時--cc產生一個選項combined diff。這是顯示與 git-diff [1]或 git-show [1]合并時的默認格式。另請注意，您可以-m選擇這些命令中的任何一個來強制生成合并的單個父代的差異combined diff格式如下所示

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);

它前面有一個“git diff”頭，看起來像這樣（當使用-c選項時）：

差異組合文件

或者像這樣（當使用--cc選項時）：

diff --cc file

它后面跟著一個或多個擴展標題行（此示例顯示與兩個父級合并）：

index <hash>，<hash> .. <hash> mode <mode>，<mode> .. <mode>新文件模式<mode>已刪除的文件模式<mode>，<mode> mode <mode>,<mode>..<mode>只有當至少有一個<mode>與其余部分不同時，該行才會出現。具有關于檢測到的內容移動（重命名和復制檢測）的信息的擴展標題被設計為與兩個<tree-ish>的差異一起工作，并且不被組合的差異格式使用。

緊接著是兩行文件/文件頭

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

類似于傳統(tǒng)unified差異格式的雙行標題，/dev/null用于表示創(chuàng)建或刪除的文件。

塊頭格式被修改以防止人們意外地將其提供給patch -p1。組合的差異格式是為了審查合并提交更改而創(chuàng)建的，并不適用于應用。這個改變類似于擴展index頭中的改變：@@@ <從文件范圍到<從文件范圍到<到文件范圍> @@@有（父數+ 1）個@字符不同于傳統(tǒng)的unifieddiff格式，它顯示兩個文件A和B，其中有一列-（減號 - 出現在A中，但在B中刪除），+（加 - 在A中丟失，但添加到B中） ， 要么" "（空格不變）前綴，此格式將兩個或多個文件file1，file2，...與一個文件X進行比較，并顯示X與每個fileN的區(qū)別。每個fileN的一列都被預置在輸出行中，以指出X的行與其不同。-列N中的一個字符表示該行出現在fileN 中，但它不出現在結果中。+N列中的一個字符表示該行出現在結果中，并且fileN沒有該行（換句話說，從該父母的視角添加該行）。在上面的示例輸出中，函數簽名從兩個文件中更改（因此-從file1和file2中刪除了兩個刪除，另外還有兩個刪除++意味著添加的一行不會出現在file1或file2中）。另外還有八行與file1相同，但不會出現在file2中（因此前綴為+）。當顯示時git diff-tree -c，它將合并提交的父項與合并結果（即file1..fileN是父項）進行比較。如圖所示git diff-files -c，它將兩個未解決的合并父代與正在工作的樹文件進行比較（即file1是第二階段aka“我們的版本”，file2是第三階段aka“他們的版本”）。示例    git show v1.0.0   顯示標記v1.0.0以及標記指向。   git show v1.0.0^{tree}   顯示標簽指向的樹v1.0.0。   git show -s --format=%s v1.0.0^{commit}   顯示標簽指向的提交主題v1.0.0。   git show next~10:Documentation/README   顯示文件的內容Documentation/README因為他們是該分支最后一次承諾的第10次next。   git show master:Makefile master:t/Makefile   將分支頭部中的所述Makefiles的內容連接master在一起.DiscussionGit在某種程度上是字符編碼不可知的。

blob對象的內容是未解釋的字節(jié)序列。在核心層面沒有編碼翻譯。

• 路徑名以 UTF-8標準化形式C編碼。這適用于樹對象，索引文件，ref 名稱，以及命令行參數，環(huán)境變量和配置文件中的路徑名.git/config（請參閱 git-config [1]） ，gitignore [5]，gitattributes [5]和gitmodules [5]）。請注意，核心級Git將路徑名視為非NUL字節(jié)序列，不存在路徑名編碼轉換（Mac和Windows除外）。因此，即使在使用傳統(tǒng)擴展 ASCII 編碼的平臺和文件系統(tǒng)上，使用非 ASCII 路徑名也可以工作。但是，在這些系統(tǒng)上創(chuàng)建的存儲庫在基于 UTF-8的系統(tǒng)（例如 Linux，Mac，Windows）上無法正常工作，反之亦然。此外，許多基 于Git 的工具只是假設路徑名稱為 UTF-8，并且無法正確顯示其他編碼。

• 提交日志消息通常以 UTF-8編碼，但也支持其他擴展 ASCII 編碼。這包括 ISO-8859-x，CP125x 和許多其他版本，但notUTF-16/32，EBCDIC和CJK 多字節(jié)編碼（GBK，Shift-JIS，Big5，EUC-x，CP9xx 等）。

雖然我們鼓勵提交日志消息使用UTF-8編碼，但核心和Git瓷器都設計為不強制項目使用UTF-8。如果特定項目的所有參與者發(fā)現使用遺留編碼更方便，Git不會禁止它。但是，有幾件事要牢記。

git commit和git commit-tree如果提交給它的提交日志消息看起來不像一個有效的 UTF-8 字符串，則會發(fā)出警告，除非您明確聲明您的項目使用了舊版編碼。這樣說的方式是在.git/config文件中使用 i18n.commitencoding ，如下所示：     i18n       commitEncoding = ISO-8859-1Commit 用上述設置創(chuàng)建的對象記錄i18n.commitEncoding其encoding標頭中的值。這是為了幫助稍后看到他們的其他人。缺少這個頭部意味著提交日志消息以UTF-8編碼。

git log，git show，git blame和朋友看encoding一個提交對象的報頭，并且嘗試除非另有規(guī)定重新代碼日志消息轉換成 UTF-8。您可以i18n.logOutputEncoding在.git/config文件中指定所需的輸出編碼，如下所示：

i18n         logOutputEncoding = ISO-8859-1

如果您沒有此配置變量，i18n.commitEncoding則會使用該值。

請注意，在提交對象級別強制使用 UTF-8時，我們故意選擇不重新編寫提交日志消息，因為重新編碼為 UTF-8不一定是可逆操作。