git-log(1)

SYNOPSIS

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

DESCRIPTION

コミットのログを表示します。

指定されたコミットから「親」リンクをたどることによって到達可能なコミットをリストしますが、その前に ^ が付いているコミットから到達可能なコミットは除外します。デフォルトでは、出力は時系列の逆順で表示されます。

これは集合演算と考えることができます。コマンドラインで指定されたコミットのいずれかから到達可能なコミットのセットを形成し、 ^ が前に付いたコミットのいずれかから到達可能なコミットがそのセットから差し引かれます。差し引かれた残りのコミットは、コマンドの出力に出力されるものです。他のさまざまなオプションとパスパラメータ(pats parameters)を使用して、結果をさらに制限できます。

したがって、以下のコマンド:

$ git log foo bar ^baz

は、「foo または bar から到達可能であるが、 baz からは到達できないすべてのコミットをリストする」を意味します。

特別な表記 <commit1>..<commit2> は、 ^<commit1> <commit2> の省略形として使用できます。たとえば、以下のどちらかを同じ意味で使用できます:

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

もう1つの特別な表記法は、マージに役立つ <commit1>...<commit2> です。結果として得られるコミットのセットは、2つのオペランド間の対称差(symmetric difference)です。以下の2つのコマンドは同等です:

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

このコマンドは、 git-rev-list(1) コマンドに適用可能なオプションを使用して、表示内容と方法を制御し、そして git-diff(1) コマンドに適用可能なオプションを使用して、各コミットによって導入される変更の表示方法を制御します。

OPTIONS

--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 構成オプションを使用すると、装飾からrefを除外できますが、明示的な --decorate-refs パターンは log.excludeDecoration のマッチングをオーバーライドします。

これらのオプションまたは構成設定のいずれも指定されていない場合、参照が HEAD または refs/heads/ または refs/remotes/ または refs/stash/ または refs/tags/ にマッチする場合、参照は装飾(decoration)として使用されます。

--clear-decorations

このオプションを指定すると、以前のすべての --decorate-refs または --decorate-refs-exclude オプションがクリアされ、すべての参照が含まれるようにデフォルトの装飾(decoration)フィルタが緩和されます。このオプションは、構成値 log.initialDecorationSet が all に設定されている場合に想定されます。

--source

各コミットがコマンドラインで指定のコミットのいずれかから到達できる祖先である場合、当該コミット毎にコマンドラインで指定のコミットのref名で表示します。

--[no-]mailmap

--[no-]use-mailmap

mailmapファイルを使用して、作者名(author names)とコミッター名(committer names)と電子メールアドレス(email addresses)を、正式な本名と電子メールアドレスにマップします。 git-shortlog(1) 参照。

--full-diff

このフラグがない場合、 git log -p <path>... は、指定されたパスに関連(touch)するコミットを示し、その指定されたパスについての差分を取ります。これにより、指定されたパスに関連するコミットの完全な差分が表示されます。これは、 "<path>…" がコミットのみを制限し、それらのコミットの差分を制限しないことを意味します。

これは、例えば --stat によって生成されたものなど、すべての差分ベースの出力タイプに影響することに注意してください。

--log-size

各コミットの出力に “log size <number>” という行を含めます。ここで、 <number> はそのコミットのメッセージの長さ(バイト単位)です。プログラムがスペースをコミットのメッセージ読み込み前に割り当てられるようにして、 git log 出力からログメッセージを読み取るツールを高速化することを目的としています。

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

-L:<funcname>:<file>

<file> 内で、 <start>,<end> 、または正規表現の関数名 <funcname> で指定された行範囲をトレースします。pathspec リミッターを指定することはできません。これは現在、単一のリビジョンから開始するウォークに制限されています。つまり、0個または1個の正のリビジョン引数のみを指定でき、 <start> と <end> (または <funcname>) が開始リビジョンに存在する必要があります。このオプションは複数回指定できます。これは --patch オプションの機能を含んでいます。パッチ出力は --no-patch を使用して抑制できますが、他の差分形式(つまり、 --raw, --numstat, --shortstat, --dirstat, --summary, --name-only, --name-status, --check)は現在実装されていません。

<start> と <end> は、以下のいずれかの形式です:

数値

<start> または <end> が数値の場合、絶対行番号を指定します(行は1から数えます)。
/regex/

この形式は、指定されたPOSIX正規表現に一致する最初の行を使用します。 <start> が正規表現の場合、前の -L 範囲の末尾から検索します。それ以外の場合は、ファイルの先頭から検索します。 <start> が ^/regex/ の場合、ファイルの先頭から検索します。 <end> が正規表現の場合、 <start> で指定された行から検索開始します。
+offset or -offset

これは <end> に対してのみ有効であり、 <start> で指定された行の前後の行数を指定します。

<start> と <end> の代わりに :<funcname> が指定されている場合、これは <funcname> に一致する最初の関数名行から次の関数名行までの範囲を示す正規表現です。 :<funcname> は、前の -L 範囲の末尾から検索します。それ以外の場合は、ファイルの先頭から検索します。 ^:<funcname> はファイルの先頭から検索します。関数名は、 git diff がパッチハンクヘッダーを処理するのと同じ方法で決定されます(gitattributes(5) の「Defining a custom hunk-header」参照)。

<revision-range>

指定されたリビジョン範囲のコミットのみを表示します。 <revision-range> が指定されていない場合、デフォルトで HEAD (つまり、現在のコミットにつながる履歴全体)になります。 origin..HEAD は、現在のコミット(つまり、HEAD)から到達可能なすべてのコミットを指定しますが、`origin`からは指定しません。 <revision-range> の綴り方の完全なリストについては、 gitrevisions(7) の「Specifying Ranges」節を参照してください。

[--] <path>…

指定されたパスに一致するファイルがどのようになったかを説明するのに必要十分なコミットのみを表示します。詳細およびその他の簡略化モードについては、以下の「History Simplification」を参照してください。

混乱が生じた場合、パスをオプションまたはリビジョン範囲から分離するために、パスの前に -- を付ける必要がある場合があります。

Commit Limiting

ここで説明されている特別な表記法を使用してリストする必要があるコミットの範囲を指定することに加えて、追加のコミット制限が適用される場合があります。

より多くのオプションを使用すると、通常、出力がさらに制限されます(たとえば、 --since=<date1> は <date1> より新しいコミットに制限され、 --grep=<pattern> と一緒に使用すると、ログメッセージに <pattern> と一致する行があるコミットにさらに制限されます)。

注意: これらは、 --reverse などのコミット順序およびフォーマットオプションの前に適用されることに注意してください。

-<number>

-n <number>

--max-count=<number>

出力するコミットの数を制限します。

--skip=<number>

コミット出力の表示を開始する前に、number 個のコミットをスキップします。

--since=<date>

--after=<date>

指定の日付よりも新しいコミットを表示します。

--since-as-filter=<date>

特定の日付より新しいすべてのコミットを表示します。これは、特定の日付より古い最初のコミットで停止するのではなく、範囲内のすべてのコミットを訪問します。

--until=<date>

--before=<date>

指定の日付より古いコミットを表示します。

--author=<pattern>

--committer=<pattern>

コミット出力を、指定されたパターン(正規表現)に一致する作者(author)/コミッター(committer)ヘッダー行を持つものに制限します。複数の --author=<pattern> がある場合、作者が指定されたパターンのいずれかに一致するコミットが選択されます(複数の --committer=<pattern> の場合も同様)。

--grep-reflog=<pattern>

コミット出力を、指定されたパターン(正規表現)に一致するreflogエントリを持つものに制限します。複数の --grep-reflog を使用すると、指定されたパターンのいずれかに一致するreflogメッセージを持つコミットが選択されます。 --walk-reflogs が使用されていない限り、このオプションを使用するとエラーになります。

--grep=<pattern>

コミット出力を、指定されたパターン(正規表現)に一致するログメッセージを持つものに制限します。複数の --grep=<pattern> を使用すると、指定されたパターンのいずれかにメッセージが一致するコミットが選択されます(全てに一致するコミットだけを選択したい場合、--all-match を参照してください)。

--notes が有効な場合、ノートからのメッセージは、ログメッセージの一部であるかのようにマッチングされます。

--all-match

コミット出力を、少なくとも1つに一致するものではなく、指定されたすべての --grep に一致するものに制限します。

--invert-grep

コミット出力を、 --grep=<pattern> で指定されたパターンと一致しないログメッセージを持つものに制限します。

-i

--regexp-ignore-case

大文字小文字に関係なく、正規表現の制限パターンに一致します。

--basic-regexp

制限パターンを基本正規表現として扱います。これがデフォルトです。

-E

--extended-regexp

制限パターンを、デフォルトの基本正規表現の代わりに拡張正規表現として扱います。

-F

--fixed-strings

制限パターンを固定文字列として扱います(パターンを正規表現として解釈しないでください)。

-P

--perl-regexp

制限パターンをPerl互換の正規表現として扱います。

これらのタイプの正規表現のサポートは、コンパイル時オプションに依存します。Gitが当該のサポート付きでコンパイルされていない場合、このオプションを提供すると、Gitが死にます(die)。

--remove-empty

指定されたパスがツリーから見えなくなったら停止(stop)します。

--merges

マージコミットのみを印刷します。これは --min-parents=2 とまったく同じです。

--no-merges

複数の親を持つコミットを出力しない。これは --max-parents=1 とまったく同じです。

--min-parents=<number>

--max-parents=<number>

--no-min-parents

--no-max-parents

量の多少に関わらず、とにかく複数の親コミットがあるコミットのみを表示します。特に、 --max-parents=1 は --no-merges と同じであり、 --min-parents=2 は --merges と同じです。 --max-parents=0 はすべてのルートコミットを提供し、 --min-parents=3 はすべてのタコ足マージ(octopus merges)を示します。

--no-min-parents と --no-max-parents は、これらの制限を(制限なしに)再度リセットします。同等の形式は、 --min-parents=0 (すべてのコミットに0個以上の親があります)および --max-parents=-1 (マイナスの数は上限がないことを示します)です。

--first-parent

インクルードするコミットを探すとき、マージ・コミットの最初の親コミットのみをたどります。このオプションは、特定のトピックブランチの進化を表示するときに、より良い概要を提供できます。トピックブランチへのマージは、時々更新されるアップストリームに調整することだけである傾向があり、このオプションを使用すると、そのようなマージによって履歴に取り込まれた個々のコミットを無視できます。

このオプションは、マージコミットのデフォルトのdiff形式も first-parent に変更します。詳細については、 --diff-merges=first-parent を参照してください。

--exclude-first-parent-only

( ^ を使用して)除外するコミットを見つけるときは、判明したマージ・コミットの最初の親コミットのみに従います。任意のマージが有効なトピック・ブランチの変更になる可能性がある場合、これを使用して、リモート・ブランチから分岐したポイントからトピック・ブランチ内の一連の変更を見つけることができます。

--not

次に現れる --not までの間、後続のすべてのリビジョン指定子の ^(カレット)接頭辞(またはその欠如)の意味を逆にします。

--all

refs/ 内のすべてのrefが HEAD とともに、コマンドラインに <commit> としてリストされているかのように見せかけます。

--branches[=<pattern>]

refs/heads 内のすべてのrefがコマンドラインに <commit> としてリストされているかのように見せかけます。 <pattern> が指定されている場合、ブランチを指定されたシェルグロブ(shell glob)に一致するものに制限します。パターンに "?" または "*" または "[" がない場合、最後に "/*" が含まれます。

--tags[=<pattern>]

refs/tags 内のすべてのrefがコマンドラインに <commit> としてリストされているかのように見せかけます。 <pattern> が指定されている場合は、指定されたシェルグロブ(shell glob)に一致するタグにタグを制限します。パターンに "?" または "*" または "[" がない場合、最後に "/*" が含まれます。

--remotes[=<pattern>]

refs/remotes 内のすべてのrefがコマンドラインに <commit> としてリストされているかのように見せかけます。 <pattern> が指定されている場合、リモート追跡ブランチを指定されたシェルグロブ(shell glob)に一致するものに制限します。パターンに "?" または "*" または "[" がない場合、最後に "/*" が含まれます。

--glob=<glob-pattern>

シェルグロブ <glob-pattern> に一致するすべてのrefがコマンドラインに <commit> としてリストされているかのように見せかけます。先頭の refs/ は、欠落している場合は自動的に先頭に追加されます。パターンに "?" または "*" または "[" がない場合、最後に "/*" が含まれます。

--exclude=<glob-pattern>

次の --all または --branches または --tags または --remotes または --glob が別の方法で考慮する <glob-pattern> に一致するrefを含めないでください。このオプションを繰り返すと、次の --all または --branches または --tags または --remotes または --glob オプションまで除外パターンが蓄積されます(他のオプションまたは引数は、蓄積されたパターンをクリアしません)。

与えられたパターンは、それぞれ --branches または --tags または --remotes に適用される場合、 refs/heads または refs/tags または refs/remotes で始まるべきではありません。 --glob または --all に適用する場合は、 refs/ で始める必要があります。末尾の "/*" を意図している場合は、明示的に指定する必要があります。

--reflog

reflogsで言及されているすべてのオブジェクトがコマンドラインに <commit> としてリストされているかのように見せかけます。

--alternate-refs

代替リポジトリのref先端として言及されているすべてのオブジェクトがコマンドラインにリストされているかのように見せかけます。代替リポジトリは、オブジェクトディレクトリが objects/info/alternates で指定されているリポジトリです。インクルードされたオブジェクトのセットは、 core.alternateRefsCommand などによって変更できます。 git-config(1)を参照してください。

--single-worktree

デフォルトでは、作業ツリーが複数ある場合、 --all と -reflog と --indexed-objects では、すべての作業ツリーが検査されます(git-worktree(1)を参照)。このオプションは、現在の作業ツリーのみを調べるように強制します。

--ignore-missing

入力に無効なオブジェクト名が含まれている場合、そもそもその不正な入力が行われていないかのように見せかけます。

--bisect

コマンドラインで、bad bisection ref refs/bisect/bad がリストされ、その後に --not と good bisection ref refs/bisect/good-* が続くかのように見せかけます。

--stdin

コマンドラインにリストされている <commit> に加えて、標準入力からそれらを読み取ります。 -- 区切り文字が表示された場合は、コミットの読み取りを停止し、パスの読み取りを開始して結果を制限します。

--cherry-mark

--cherry-pick（以下を参照）と同様ですが、同等のコミットを省略せずに = と印し、同等でないコミットを + と印します。

--cherry-pick

コミットの組を対称差(symmetric difference)に制限する場合、「反対側」の別のコミットと同じ変更を導入するコミットを省略します。

たとえば、A と B の2つのブランチがある場合、それらの片側だけですべてのコミットを一覧表示する通常の方法は、 --left-right を使用することです(--left-right オプションの説明の以下の例を参照してください)。ただし、他のブランチからは(ブランチAと重複しない)厳選されたコミットが表示されます(たとえば、「3rd onb」はブランチAからチェリーピックされる可能性があります)。このオプションを使用すると、そのようなコミットのペアは出力から除外されます。

--left-only

--right-only

リストは、対称差のそれぞれの側でのみコミットします。つまり、 --left-right で < と印されるのだけか、あるいは --left-right で > と印されるものだけです。

たとえば、 --cherry-pick --right-only A...B は、 A にある、または A のコミットとパッチと同等のコミットを B から省略します。つまり、これは git cherry A B からの + コミットをリストします。より正確に書くと、 --cherry-pick --right-only --no-merges により正確なリストを提供します。

--cherry

--right-only --cherry-mark --no-merges の同義語です。出力を私たちの側のコミットに制限し、フォークされた履歴の反対の側に適用されたものを、 git cherry upstream mybranch と同様に git log --cherry upstream...mybranch でマークするのに役立ちます。

-g

--walk-reflogs

コミットの祖先チェーンをたどる代わりに、 reflogエントリを最新のものから古いものに移動します。このオプションを使用する場合、除外するコミットを指定することはできません(つまり、 ^commit や commit1..commit2 や commit1...commit2 表記は使用できません)。

(明らかな理由で、)oneline と reference 以外の --pretty 形式では、これにより、出力にreflogから取得された2行の追加情報が含まれます。出力のreflog指定子は、 ref@{Nth} (Nth はreflogの逆時系列インデックス(reverse-chronological index))または ref@{timestamp} (そのエントリのタイムスタンプ付き)として表示されます。表示は下記のいくつかのルールに依存します:

開始点が ref@{Nth} として指定されている場合は、インデックス形式を表示します。
開始点が ref@{now} として指定されている場合は、タイムスタンプ形式を表示します。
上記のどちらも使用されていないが、コマンドラインで --date が指定されている場合は、 --date で要求された形式でタイムスタンプを表示します。
それ以外の場合は、インデックス形式を表示します。

--pretty = oneline では、コミットメッセージの前にこの情報が同じ行に付けられます。このオプションを --reverse と組み合わせることはできません。 git-reflog(1)も参照してください。

--pretty=reference では、この情報はまったく表示されません。

--merge

マージが失敗した後、競合があり、マージするすべてのheadに存在しないファイルに関連(touch)するrefを表示します。

--boundary

除外された境界コミットを出力します。境界コミットの前には - が付いています。

History Simplification

特定の<path>を変更するコミットなど、履歴の一部のみに関心がある場合があります。ただし、「履歴の簡略化」(History Simplification)は2つの部分から成ります。履歴を簡略化するためにはさまざまな戦略があるためです。その1つはコミットの選択であり、もう1つはそれを行う方法です。

以下のオプションは、表示するコミットを選択します:

<paths>: 指定された<パス>を変更するコミットが選択されます。
--simplify-by-decoration: いくつかのブランチまたはタグによって参照されるコミットが選択されます。

注意: 意味のある重要な履歴のために、追加のコミットを表示できることに注意してください。

以下のオプションは、簡略化の実行方法に影響します。

Default mode: 履歴を、ツリーの最終状態を説明する最も単純な履歴に単純化します。最終結果が同じである場合(つまり、同じコンテンツのブランチをマージする場合)、いくつかの傍流ブランチ(side branches)を削除するため、最も単純です。
--show-pulls: デフォルトモードからのすべてのコミットを含めますが、最初の親へのTREESAMEではなく、後の親へのTREESAMEであるマージコミットも含めます。このモードは、ブランチに変更を「最初に導入した」マージコミットを表示するのに役立ちます。(訳注:TREESAME=pathspecが全く同一であるツリー)
--full-history: デフォルトモードと同じですが、一部の履歴を削除しません。
--dense: 選択したコミットのみが表示され、重大で意味のある履歴を持つコミットもいくつか表示されます。
--sparse: 簡略化された履歴内のすべてのコミットが表示されます。
--simplify-merges: このマージに寄与する選択されたコミットがないため、結果の履歴からいくつかの不要なマージを削除するための`--full-history`への追加オプション。
--ancestry-path[=<commit>]: 表示するコミットの範囲を指定すると(例: commit1..commit2 または commit2 ^commit1)、その範囲内で <commit> の祖先、<commit> の子孫、または <commit> 自身であるコミットのみを表示します。コミットが指定されていない場合は、commit1 (範囲の除外部分) を <commit> として使用します。複数回渡すことができます。その場合、あるコミットが指定されたコミットのいずれかであるか、それらのいずれかの祖先または子孫である場合、そのコミットは含まれます。

より詳細な説明は以下のとおりです。

<paths> として foo を指定したとします。 foo !TREESAME を変更するコミットを呼び出し、残りをTREESAMEと呼びます。( foo のためにフィルタリングされた差分では、それぞれ異なって見えたりたり等しく見えたりします。）

以下、簡略化設定の違いを説明するために、同じ履歴例を使います。このコミットグラフでは、ファイル foo をフィルタリングしていると想定しています:

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

履歴 A---Q の水平線は、各マージの最初の親と見なされます。その各コミットは以下のとおりです:

I は最初のコミットであり、ファイル foo が内容 “asdf” で存在し、ファイル quux は内容 “quux” で存在します。最初のコミットは空のツリーと比較されるため、I は !TREESAME です。
A では、 foo には “foo” だけが含まれています。
B には A と同じ変更が含まれています。そのマージ M は些細なことであり、したがってすべての親にとって TREESAME です。
C は foo を変更しませんが、そのマージ N はそれを “foobar” に変更するので、どの親にとっても TREESAME ではありません。
D は foo を “baz” に設定します。そのマージ O は、 N と D から “foobarbaz” への文字列を結合します。つまり、どの親にとっても TREESAME ではありません。
E は quux を “xyzzy” に変更し、そのマージ P は文字列を “quuxxyzzy” に結合します。 P は O に対して TREESAME ですが、 E に対してはそうではありません。
X は、新ファイル side を追加し、 Y がそれを変更した独立したルートコミットです。 Y は X へのTREESAMEです。そのマージ Q は P に side を追加し、 Q は P にはTREESAMEですが、Y に対してはそうではありません。

rev-list は、 --full-history および/または、( --parents または --children を介して)親の書き換えが使用されているかどうかに基づいて、コミットを含めたり除外したりして、履歴を逆方向にウォークスルーします。以下の設定が可能です。

Default mode

コミットは、どの親に対してもTREESAMEでない場合に含まれます(これは変更できますが、以下の --sparse を参照してください)。コミットがマージであり、一方の親に対するTREESAMEであった場合は、その親のみをフォローします。(TREESAMEの親が複数ある場合でも、そのうちの1つだけをフォローします)。それ以外の場合は、すべての親をフォローします。

これにより、以下のようになります:

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

TREESAMEの親のみに従うルールが利用可能な場合は、 B を検討対象から完全に削除したことに注意してください。 C は N を介して考慮されましたが、しかしそれはTREESAMEです。ルートコミットは空のツリーと比較されるため、 I は !TREESAME です。

親子関係は --parents でのみ表示されますが、デフォルトモードで選択されたコミットには影響しないため、親の行を示しました。

--full-history without parent rewriting

このモードは、デフォルトとはある一点で異なります。つまり、いずれかの親に対してTREESAMEであっても、常にマージのすべての親に従います。マージの複数の側にコミットが含まれている場合でも、これはマージ自体が含まれていることを意味するものではありません！例では以下のようになります。

        I  A  B  N  D  O  P  Q

M は、両方の親にとってTREESAMEであるため、除外されました。 E と C と B をすべて巡りましたが、 B だけが !TREESAME だったので、他は表示されません。

注意: 親の書き換え(rewrite)がないと、コミット間の親子関係について話す(talk)ことは実際には不可能であるため、それらが切断されている(disconnected)ことを示していることに注意してください。

--full-history with parent rewriting

通常のコミットは !TREESAME の場合にのみ含まれます(これは変更できますが、以下の --sparse を参照してください)。

マージは常に含まれます。ただし、親リストは書き直されます。各親に沿って、自分自身に含まれていないコミットを削除します。これにより以下のようになります。

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

上記を書き直さずに --full-history と比較してください。 E はTREESAMEであるため削除されましたが、Pの親リストは E の親 I を含むように書き直されていることに注意してください。 C と N および X と Y と Q についても同じことが起こりました。

上記の設定に加えて、あなたはTREESAMEが包含に影響を与えるかどうかを変更できます:

--dense

巡ったコミットは、親にとってTREESAMEでない場合に含まれます。

--sparse

巡ったすべてのコミットが含まれます。

--full-history がなくても、これによりマージが単純化されることに注意してください。親の1つがTREESAMEの場合、その1つだけに従うため、マージの反対側を巡ることはありません。

--simplify-merges

最初に、親を書き換えた --full-history と同じ方法で履歴グラフを作成します(上記を参照)。

それから、以下のルールに従って、各コミット C を最終履歴内の置換 C' に単純化します:

C' を C にセットします。
C' の各親 P をその簡略化された P' に置き換えます。その過程で、他の親の祖先であるか、ルートである親を削除すると、TREESAMEが空のツリーにコミットされ、重複が削除されますが、TREESAMEであるすべての親を削除しないように注意してください。
この親の書き換え後、 C' がルートまたはマージコミット(0または >1 の親を持つ)、境界コミット、または !TREESAMEである場合、それは残ります。それ以外の場合は、唯一の親に置き換えられます。

この効果は、親の書き換えを使用した --full-history と比較することで最もよく示されます。例は以下のようになります:

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

注意: --full-history に対する N と P と Q の主な違いに注意してください:

N の親リストは、他の親 M の祖先であるため、 I が削除されました。それでも、 !TREESAME なので N が残りました。
P の親リストも同様に I が削除されました。 P は、親が1つで TREESAMEであるため、完全に削除されました。
Q の親リストでは、 Y が X に簡略化されていました。その後、 X はTREESAMEルートであったため、削除されました。 Q は、親が1つで TREESAMEであるため、完全に削除されました。

利用可能な別の簡略化モードがあります:

--ancestry-path[=<commit>]

表示されるコミットを <commit> の祖先、または <commit> の子孫、または <commit> 自身に制限します。

ユースケースの例として、以下のコミット履歴について考えます:

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

通常の D..M は、 M の祖先であるコミットのセットを計算しますが、 D の祖先であるコミットは除外します。これは、「 M には D には存在しなかったものがある」という意味で、 D 以降の M に至るまでの歴史に何が起こったのかを知るのに役立ちます。この例の結果は、 A と B (そしてもちろん D 自体)を除くすべてのコミットになります。

ただし、 M のコミットが D で入ったバグで汚染されており、修正が必要な場合は、実際には D の子孫である D..M のサブセットのみを表示する必要があります。つまり、 C と K を除外します。これはまさに --ancestry-path オプションが行うことです。これを D..M 範囲に適用すると、以下のようになります:

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

--ancestry-path の代わりに --ancestry-path=D を使用することもできます。これは、D..M 範囲に適用された場合と同じことを意味しますが、より明示的です。

代わりに、この範囲内の特定のトピックに関心があり、そのトピックによって影響を受けるすべてのコミットに関心がある場合、祖先パスにそのトピックを含む D..M のサブセットのみを表示したい場合があります。たとえば、--ancestry-path=H D..M を使用すると、以下のようになります:

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

一方、--ancestry-path=K D..M は以下のようになります

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

別のオプション --show-pulls について説明する前に、新しいサンプル履歴を作成する必要があります。

簡略化された履歴を見るときにユーザーが直面する一般的な問題は、ファイルを変更したことがわかっているコミットが、ファイルの簡略化された履歴に表示されないことです。そこで、新しい例を示し、その場合に --full-history や --simplify-merges などのオプションがどのように機能するかを示しましょう。

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

この例では、 I が file.txt を作成し、それが A と`B` と X にてさまざまな方法で変更されたとします。ひとり親のコミット C と Z と Y は file.txt を変更していません。マージコミット M は、マージの競合を解決して、 A と B の両方の変更を含めることによって作成されたため、どちらにもTREESAMEではありません。ただし、マージコミット R は、 M の file.txt`の内容を無視し、 `X の file.txt の内容のみを取得することによって作成されました。したがって、 R は X へのTREESAMEですが、 M はそうではありません。最後に、 N を作成するための自然なマージ解決は、 R で file.txt の内容を取得することです。したがって、 N は C ではなく R へのTREESAMEです。マージコミット O と P は、最初の親にはTREESAMEですが、2番目の親である Z と Y にはついてはそうではありません。

デフォルトモードを使用する場合、 N と R は両方ともTREESAMEの親を持っているため、これらのエッジはウォークされ、他のエッジは無視されます。結果の履歴グラフは以下のとおりです:

        I---X

--full-history を使用する場合、Gitはすべてのエッジを巡ります。これにより、コミット A と B とマージ M が検出されますが、マージコミット O と P も明らかになります。親を書き換えると、結果のグラフは以下のようになります:

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

ここで、マージコミット O と P は、実際には file.txt への変更を提供しなかったため、余分なノイズを提供します。古いバージョンの file.txt に基づいたトピックのみをマージしました。これは、多くの寄稿者が並行して作業し、トピックブランチを単一のトランクに沿ってマージするワークフローを使用するリポジトリの一般的な問題です。 --full-history の結果には、関連のない多くのマージが表示されます。

--simplify-merges オプションを使用すると、コミット O と P が結果から消えます。これは、 O と P の書き直された2番目の親が、最初の親から到達可能であるためです。これらのエッジが削除されると、コミットは、親にとってTREESAMEである単一の親のコミットのように見えます。これはコミット N にも発生し、以下のような履歴ビューが表示されます:

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

このビューでは、 A と B と X からの重要なひとり親の変更がすべて表示されます。また、慎重に解決されたマージ M とそれほど慎重に解決されていないマージ R も表示されます。これは通常、コミット A と B がデフォルトのビューの履歴から「消えた」理由を判断するのに十分な情報です。ただし、このアプローチにはいくつかの問題があります。

最初の問題はパフォーマンスです。以前のオプションとは異なり、 --simplify-merges オプションでは、単一の結果を返す前にコミット履歴全体をウォークする必要があります。これにより、非常に大規模なリポジトリでこのオプションを使用するのが難しくなる可能性があります。

2番目の問題は監査の1つです。多くの寄稿者が同じリポジトリで作業している場合、どのマージコミットが重要なブランチに変更を導入したかが重要です。上記の問題のあるマージ R は、重要なブランチにマージするために使用されたマージコミットではない可能性があります。代わりに、マージ N を使用して R と X を重要なブランチにマージしました。このコミットには、変更 X がコミットメッセージの A と B からの変更を上書きするようになった理由に関する情報が含まれている可能性があります。

--show-pulls

デフォルトの履歴に表示されるコミットに加えて、最初の親にはTREESAMEではなく、後の親にはTREESAMEである各マージコミットを表示します。

マージコミットが --show-pulls に含まれている場合、マージは別のブランチから変更を「プル」したかのように扱われます。この例で --show-pulls を使用すると(他のオプションは使用しない場合、)結果のグラフは行かのようになります:

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

ここで、コミット X と R をそれぞれベースブランチにプルしたため、マージコミット R と N が含まれています。これらのマージは、コミット A と B がデフォルトの履歴に表示されない理由です。

--show-pulls が --simplify-merges とペアになっている場合、グラフには必要なすべての情報が含まれます:

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

M は R から到達可能であるため、 N から M へのエッジが単純化されていることに注意してください。ただし、 N は、変更 R をメインブランチに「プル」したため、重要なコミットとして履歴に表示されます。

--simplify-by-decoration オプションを使用すると、タグで参照されていないコミットを省略して、履歴のトポロジの全体像のみを表示できます。コミットは、(1)タグによって参照されている場合、または (2)コマンドラインで指定されたパスの内容を変更した場合に、!TREESAMEとしてマークされます(つまり、上記の履歴簡略化ルールの後に保持されます)。他のすべてのコミットはTREESAMEとしてマークされます(簡略化される可能性があります)。

Commit Ordering

デフォルトでは、コミットは新しい順に表示されます。

--date-order

すべての子が表示されるまで親を表示しませんが、それ以外の場合はコミットタイムスタンプの順序でコミットを表示します。

--author-date-order

すべての子が表示されるまで親を表示しませんが、それ以外の場合は、作者(author)のタイムスタンプ順にコミットを表示します。

--topo-order

すべての子が表示されるまで親を表示せず、複数の履歴行が混在するコミットを表示しないようにします。

たとえば、以下のようなコミット履歴があります:

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

ここで、数字はコミットタイムスタンプの順序を示し、 gitrev-list と --date-order のある友達は、タイムスタンプの順序でコミットを示します。つまり、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）が表示されます。2つの並列開発トラックからのコミットが混在して表示されないようにするために、いくつかの古いコミットが新しいコミットの前に表示されます。

--reverse

表示するように選択したコミットを逆の順序で出力します(上記の Commit Limiting 節を参照)。 --walk-reflogs と組み合わせることはできません。

Object Traversal

これらのオプションは、主にGitリポジトリのパッキングを対象としています。

--no-walk[=(sorted|unsorted)]: 指定されたコミットのみを表示し、祖先をトラバースしない。範囲が指定されている場合、これは効果がありません。引数 unsorted が指定されている場合、コミットはコマンドラインで指定された順序で表示されます。それ以外の場合( sorted または引数が指定されていない場合)、コミットはコミット時間の逆順に表示されます。 --graph と組み合わせることはできません。
--do-walk: 以前の --no-walk を上書きします。

Commit Formatting

--pretty[=<format>]

--format=<format>

コミットログの内容を指定された形式できれいに印刷(pretty-print)します。 <format> は oneline、short、medium、full、fuller、reference、email、raw、format:<string>、tformat:<string> のいずれかになります。 <format> が上記のいずれでもなく、「%プレースホルダー」が含まれている場合、 --pretty=tformat:<format> が指定されたかのように動作します。

各フォーマットの詳細については、「PRETTY FORMATS」セクションを参照してください。 =<format> の部分を省略すると、デフォルトで medium になります。

注意: リポジトリー構成でデフォルトのpretty formatを指定できます(git-config(1) 参照)。

--abbrev-commit

40バイトの16進コミットオブジェクト名全体を表示する代わりに、オブジェクトに一意の名前を付けるプレフィックスを表示します。 "--abbrev=<n>" (表示されている場合はdiff出力も変更します)オプションを使用して、プレフィックスの最小長を指定できます。

これにより、80桁幅の端末を使用している人にとって "--pretty=oneline" がずっと読みやすくなるはずです。

--no-abbrev-commit

完全な40バイトの16進コミットオブジェクト名を表示します。これにより、明示的または "--oneline" などの他のオプションによって暗黙的に示される --abbrev-commit が無効になります。また、 log.abbrevCommit 変数をオーバーライドします。

--oneline

これは、 "--pretty=oneline --abbrev-commit" を一緒に使用するための省略形です。

--encoding=<encoding>

コミットオブジェクトは、ログメッセージに使用される文字エンコードをエンコードヘッダーに記録します。このオプションを使用して、ユーザーが好むエンコーディングでコミットログメッセージを再コーディングするようにコマンドに指示できます。配管以外のコマンドの場合、これはデフォルトでUTF-8になります。オブジェクトが X でエンコードされていると主張し、 X で出力している場合、オブジェクトをそのまま出力することに注意してください。これは、元のコミットの無効なシーケンスが出力にコピーされる可能性があることを意味します。同様に、 iconv(3) がコミットの変換に失敗した場合、元のオブジェクトをそのまま黙って出力します。

--expand-tabs=<n>

--expand-tabs

--no-expand-tabs

出力に表示する前に、ログメッセージでタブ展開を実行します(タブ幅を <n> とみなして <n> 境界に揃うように空白で調整する)。 --expand-tabs は --expand-tabs=8 の省略形であり、 --no-expand-tabs は --expand-tabs=0 の省略形です。タブの展開を無効にします。

デフォルトでは、タブはログメッセージを4つのスペースでインデントするきれいな形式(pretty formats)で展開されます(つまり、medium (これがデフォルト) と full と fuller)。

--notes[=<ref>]

コミットログメッセージを表示するときに、コミットに注釈を付けるnotes(git-notes(1) 参照)を表示します。これは、コマンドラインに --pretty 、--format または --oneline オプションが指定されていない場合の、 git log と git show と ` git whatchanged` コマンドのデフォルトです。

デフォルトでは、表示されるnotesは、 core.notesRef および notes.displayRef 変数(または対応する環境変数オーバーライド)にリストされているnote refからのものです。詳細については git-config(1) を参照してください。

オプションの <ref> 引数を使用して、refを使用して表示するnotesを検索します。 refは、 refs/notes/ で始まる完全なrefnameを指定できます。 notes/ で始まるか、 refs/ で始まるか、それ以外で始まる場合、 refs/notes/ が接頭辞として付けられ、refのフルネームを形成します。

複数の --notes オプションを組み合わせて、表示するノートを制御できます。例: "--notes=foo" は "refs/notes/foo" からのnotesのみを表示します。 "--notes=foo --notes" は、 "refs/notes/foo" とデフォルトのnotes ref(s) の両方のnotesを表示します。

--no-notes

notesを表示しないでください。これは、notesが表示されるnotes refのリストをリセットすることにより、上記の --notes オプションを無効にします。オプションは、コマンドラインで指定された順序で解析されます。 "--notes --notes=foo --no-notes --notes=bar" は、 "refs/notes/bar" からのnotesのみを表示します。

--show-notes[=<ref>]

--[no-]standard-notes

これらのオプションは非推奨です。代わりに、上記の --notes/--no-notes オプションを使用してください。

--show-signature

署名を gpg --verify に渡して、署名されたコミットオブジェクトの有効性を確認し、出力を表示します。

--relative-date

--date=relative と同じ。

--date=<format>

--pretty を使用する場合など、人間が読める形式で表示される日付に対してのみ有効になります。 log.date 構成変数(config variable)は、logコマンドの --date オプションのデフォルト値を設定します。デフォルトでは、日付は元のタイムゾーン(コミッターの、または作者のいずれか)で表示されます。フォーマットに -local が追加されている場合(例: iso-local )、代わりにユーザーのローカルタイムゾーンが使用されます。

--date=relative は、現在の時刻を基準にした日付を示します。例: “2 hours ago” 。 -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 は、エポック(1970-01-01 00:00:00 UTC)からの秒数、スペース、UTCからのオフセット(+ または - の付いた4桁数字で、最初の2つは時間、次の2つは分です)。つまり、タイムスタンプが strftime("%s %z") でフォーマットされているかのようになります。 -local オプションは、seconds-since-epoch値(常にUTCで測定されます)には影響しませんが、付随するタイムゾーン値を切り替えることに注意してください。

--date=human は、タイムゾーンが現在のタイムゾーンと一致しない場合はタイムゾーンを表示し、一致する場合は日付全体を印刷しません(つまり、「今年」の日付の場合は年の印刷をスキップしますが、何があったか覚えてるような過去数日については日付自体もスキップします)。古い日付の場合、時と分も省略されます。

--date=unix は、日付をUnixエポックタイムスタンプ(1970年からの秒数)として表示します。 --raw と同様に、これは常にUTCであるため、 ` -local` は効果がありません。

--date=format:... は、内部で処理される%sと%zと%Zを除いて、フォーマット ... をあなたのシステムの strftime に送ります。 --date=format:%c を使用して、システムロケールの推奨形式で日付を表示します。フォーマットプレースホルダーの完全なリストについては、 strftime マニュアルを参照してください。 -local を使用する場合、正しい構文は --date=format-local:... です。

--date=default はデフォルトの形式であり、いくつかの例外を除いて --date=rfc2822 に似ています:

曜日の後にコンマはありません
ローカルタイムゾーンを使用する場合、タイムゾーンは省略されます

--parents

コミットの親も出力します( "commit parent…" の形式で)。親の書き換えも可能にします。上記「History Simplification」を参照してください。

--children

コミットの子も出力します( "commit child…" の形式で)。親の書き換えも可能にします。上記「History Simplification」を参照してください。

--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 と組み合わせることはできません。

これにより、親の書き換えが可能になります。上記「History Simplification」を参照してください。

これは、デフォルトで --topo-order オプションを意味しますが、 --date-order オプションも指定できます。

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

--graph を使用しない場合、すべての履歴ブランチがフラット化されるため、2つの連続するコミットが線形ブランチに属していないことがわかりにくくなる可能性があります。このオプションは、その場合、それらの間に障壁を置きます。 <barrier> が指定されている場合、デフォルトの障壁文字列の代わりに <barrier> が表示されます。

PRETTY FORMATS

コミットがマージであり、 pretty-format が oneline または email または raw で無い場合、 Author: 行の前に追加の行が挿入されます。この行は "Merge: " で始まり、先祖のコミットのハッシュがスペースで区切られて出力されます。履歴の表示を制限している場合、たとえば、特定のディレクトリまたはファイルに関連する変更のみに関心がある場合、リストされたコミットは必ずしも直接の親コミットのリストではない可能性があることに注意してください。

いくつかの組み込みフォーマットがあります。そして以下で説明するように、 pretty.<name> 構成オプション(config option)を別のフォーマット名または 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 オプションが明示的に指定されていない限り、日付は --date=short でフォーマットされます。formatプレースホルダーを使用する他の format: と同様に、その出力は、 --decorate や --walk-reflogs などの他のオプションの影響を受けません。

email

From <hash> <date>
From: <author>
Date: <author-date>
Subject: [PATCH] <title-line>

<full-commit-message>

mboxrd

email と同様ですが、コミットメッセージの "From " で始まる行(前に0個以上の > が付いている)は > でクォートされているため、新しいコミットの開始と混同されることはありません。
raw

raw 形式は、コミットオブジェクトに格納されているとおりにコミット全体を正確に表示します。とりわけ --abbrev または --no-abbrev のどちらが使用されているかに関係なく、ハッシュは完全に表示され、「親」(parents)情報は、移植や履歴の単純化を考慮せずに、真の親のコミットを示します。この形式は、コミットの表示方法に影響しますが、いわゆる git log --raw の差分の表示方法ではありません。生のdiff形式で完全なオブジェクト名を取得するには、 --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
  
  改行(newline)
  
  %%
  
  `%`そのもの
  
  %x00
  
  16進数のバイト値を出力
- うしろのプレースホルダーのフォーマッティングに影響するプレースホルダー:
  
  %Cred
  
  赤色に切り替える
  
  %Cgreen
  
  緑色に切り替える
  
  %Cblue
  
  青色に切り替える。
  
  %Creset
  
  色をリセットする
  
  %C(...)
  
  git-config(1) の「CONFIGURATION FILE」の Values で説明されている色の指定。デフォルトでは、色はログ出力が有効になっている場合にのみ表示されます'(color.diff または color.ui または --color によって、ターミナルに出す場合は前者の auto 設定を尊重します)。 %C(auto,...) は、 default の歴史的同義語として受け入れられます(例: %C(auto,red))。 %C(always,...) を指定すると、色が有効になっていない場合でも色が表示されます(この形式やgitが色付けする可能性のある他のすべてのものを含め、出力全体の色を有効にするために --color=always の使用を検討してください)。 auto のみ(つまり、 %C(auto))は、色が再び切り替わるまで、これに続くプレースホルダーで自動色付けをオンにします。
  
  %m
  
  左(<) または右(>) または境界 (-) の印
  
  %w([<w>[,<i1>[,<i2>]]])
  
  git-shortlog(1) の -w オプションのように、行の折り返しを切り替えます。
  
  %<(<N>[,trunc|ltrunc|mtrunc])
  
  次のプレースホルダーに少なくともN列を使用させ、必要に応じて右側にスペースを埋め込みます。オプションで、出力がN列より長い場合は、先頭(ltrunc)または中間(mtrunc)または末尾(trunc)で切り捨てます。注意: 切り捨ては、 N >= 2 でのみ正しく機能することに注意してください。
  
  %<|(<N>)
  
  次のプレースホルダーを少なくともN番目の列まで取得し、必要に応じて右側にスペースを埋め込みます
  
  %>(<N>), %>|(<N>)
  
  それぞれ %<(<N>) 、 %<|(<N>) に似ていますが、左側にスペースが埋め込まれています
  
  %>>(<N>), %>>|(<N>)
  
  %>(<N>) 、 %>|(<N>) とそれぞれ似ていますが、次のプレースホルダーが指定されたよりも多くのスペースを取り、その左側にスペースがある場合は、それらのスペースを使用します。
  
  %><(<N>), %><|(<N>)
  
  それぞれ %<(<N>) 、 %<|(<N>) に似ていますが、両側にパディングがあります(つまり、テキストが中央に配置されます)
- コミットから抽出された情報に展開するプレースホルダー:
  %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
  
  作者電子メールアドレスアカウント名(local-part)(@ の前の部分)
  
  %aL
  
  作者電子メールアドレスアカウント名(local-part)(%al 参照) .mailmap に関しては git-shortlog(1) または git-blame(1) 参照)
  
  %ad
  
  作成日(フォーマットに関しては --date= オプション参照)
  
  %aD
  
  作成日 RFC2822形式
  
  %ar
  
  作成日相対(relative)形式
  
  %at
  
  作成日 UNIXタイムスタンプ形式
  
  %ai
  
  作成日 ISO 8601風形式
  
  %aI
  
  作成日厳密なISO 8601形式
  
  %as
  
  作成日短い形式(YYYY-MM-DD)
  
  %ah
  
  作成日 human形式( 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
  
  コミッター電子メールアドレスアカウント名(local-part)( @ の前の部分)
  
  %cL
  
  コミッター電子メールアドレスアカウント名(local-part)( %cl 参照) .mailmap に関しては git-shortlog(1) または git-blame(1) 参照)
  
  %cd
  
  コミッター日付(フォーマットに関しては --date= オプション参照)
  
  %cD
  
  コミッター日付 RFC2822形式
  
  %cr
  
  コミッター日付相対(relative)形式
  
  %ct
  
  コミッター日付 UNIXタイムスタンプ形式
  
  %ci
  
  コミッター日付 ISO 8601風形式
  
  %cI
  
  コミッター日付厳密なISO 8601形式
  
  %cs
  
  コミッター日付短い形式(YYYY-MM-DD)
  
  %ch
  
  コミッター日付 human形式(git-rev-list(1) の --date=human オプションのようなかんじ)
  
  %d
  
  ref名 git-log(1) の --decorate オプションみたいなの
  
  %D
  
  " (", ")" で囲ってないref名
  
  %(describe[:options])
  
  git-describe(1) のような人間が読める名前。説明できないコミットの場合は空の文字列。 describe 文字列の後には、コロンと0個以上のカンマ区切りオプションを続けることができます。タグが同時に追加または削除されると、説明に一貫性がなくなる可能性があります。
  
  tags[=<bool-value>]: 注釈付きタグ(annotated tags)だけを考慮するのではなく、軽量タグ(lightweight tags)も考慮してください。
  
  abbrev=<number>: 短縮ブジェクト名のデフォルトの 16 進数の桁数 (デフォルトは 7 で、リポジトリ内のオブジェクトの数によって異なります) を使用する代わりに、 <number> 桁を使用するか、または一意のオブジェクト名を形成するために必要な桁数。
  
  match=<pattern>: refs/tags/ プレフィックスを除いて、指定された glob(7) パターンに一致するタグのみを考慮します。
  
  exclude=<pattern>: refs/tags/ プレフィックスを除いて、指定された glob(7) パターンに一致するタグを対象にしません。
  
  %S
  
  コミットに到達したコマンドラインで指定されたref名 ( git log --source など)は、 git log でのみ機能します
  
  %e
  
  エンコーディング
  
  %s
  
  件名(subject)
  
  %f
  
  ファイル名に適した、サニタイズされた件名
  
  %b
  
  本文(body)
  
  %B
  
  生本文(raw body)(ラップされてない件名と本文)
  
  %N
  
  コミットノート(commit notes)
  
  %GG
  
  署名されたコミットの為のGPSからの生の検証メッセージ
  
  %G?
  
  G
  
  良い(good)な(有効な)署名の場合はこの文字に置換されます。
  
  B
  
  悪い署名(bad signature)の場合はこの文字に置換されます。
  
  U
  
  有効性が不明(unknown validity)な良い署名の場合はこの文字に置換されます。
  
  X
  
  期限切れ(eXpired)の良い署名の場合はこの文字に置換されます。
  
  Y
  
  期限切れのキーで作成された良い署名の場合はこの文字に置換されます。
  
  R
  
  取り消されたキーによって作成された良い署名の場合はこの文字に置換されます。
  
  E
  
  署名を確認できない場合(キーの欠落など)の場合はこの文字に置換されます。
  
  N
  
  署名がない場合の場合はこの文字に置換されます。
  
  %GS
  
  署名されたコミットの署名者の名前を表示する
  
  %GK
  
  署名されたコミットに署名するために使用されるキーを表示する
  
  %GF
  
  署名されたコミットに署名するために使用されるキーのフィンガープリントを表示する
  
  %GP
  
  署名されたコミットに署名するためにサブキーが使用された主キーのフィンガープリントを表示します
  
  %GT
  
  署名されたコミットに署名するために使用されるキーの信頼レベル(trust level)を表示します
  
  %gD
  
  reflogセレクター(例:refs/stash@{1} or 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 ID名
  
  %gN
  
  reflog ID名( .mailmap に関しては git-shortlog(1) または git-blame(1) 参照)
  
  %ge
  
  reflog ID 電子メールアドレス
  
  %gE
  
  reflog ID 電子メールアドレス( .mailmap に関しては git-shortlog(1) または git-blame(1) 参照)
  
  %gs
  
  reflog 件名
  
  %(trailers[:options])
  
  git-interpret-trailers(1) によって解釈されるようにボディのトレーラーを表示します。 trailers 文字列の後には、コロンと0個以上のカンマ区切りオプションを続けることができます。いずれかのオプションが複数回提供された場合、それぞれ最後のものが優先されます。
  
  key=<key>: 指定された <key> を持つトレーラーのみを表示します。マッチングは大文字と小文字を区別せずに行われ、末尾のコロンはオプションです。オプションが複数回指定されている場合、いずれかのキーに一致するトレーラー行が表示されます。このオプションは自動的に only オプションを有効にして、トレーラーブロック内の非トレーラー行が非表示になるようにします。それが望ましくない場合は、 only=false で無効にすることができます。たとえば、 %(trailers:key=Reviewed-by) は、キーが `Reviewed-by`のトレーラー行を表示します。
  
  only[=<bool>]: トレーラーブロックに非トレーラー行を含めるかどうかを選択します。
  
  separator=<sep>: トレーラー行の間に挿入される区切り文字を指定します。このオプションが指定されていない場合、各トレーラー行は改行文字で終了します。文字列 <sep> には、上記のリテラルフォーマットコードが含まれる場合があります。区切り文字としてコンマを使用するには、次のオプションとして解析されないよう %x2C を使用する必要があります。たとえば、 %(trailers:key=Ticket,separator=%x2C ) は、キーが Ticket であるすべてのトレーラー行をカンマとスペースで区切って表示します。
  
  unfold[=<bool>]: interpret-trailer の --unfold オプションが指定されたかのように動作させます。たとえば、 %(trailers:only,unfold=true) が展開され、すべてのトレーラー行が表示されます。
  
  keyonly[=<bool>]: トレーラーのキー部分のみを表示。
  
  valueonly[=<bool>]: トレーラーの値部分のみ表示。
  
  key_value_separator=<sep>: トレーラー行の間に挿入される区切り文字を指定します。このオプションが指定されていない場合、各トレーラーのキーと値のペアは ": " で区切られます。それ以外の場合は、上記の separator=<sep> と同じセマンティクスを共有します。

Note	一部のプレースホルダーは、リビジョントラバーサルエンジンに指定された他のオプションに依存する場合があります。たとえば、 `%g*` reflogオプションは、reflogエントリをトラバースしない限り(たとえば、 `git log -g` によって)空の文字列を挿入します。コマンドラインで `--decorate` がまだ指定されていない場合、 `%d` と `%D` プレースホルダーは「短い」(short)装飾形式を使用します。

ブール値オプションは、オプションの値 [=<bool-value>] を受け入れます。値 true 、false 、 on 、off などはすべて受け入れられます。 git-config(1) の "EXAMPLES" の "boolean" サブセクションを参照してください。ブール値オプションが値なしで指定された場合、それは有効を指定した事になります。

プレースホルダーの % の後に + (プラス記号)を追加すると、プレースホルダーが空でない文字列に展開される場合に限り、展開の直前に改行が挿入されます。

プレースホルダーの % の後に - (マイナス記号)を追加すると、プレースホルダーが空の文字列に展開された場合にのみ、展開の直前の連続するすべての改行が削除されます。

プレースホルダーの % の後に " " (スペース)を追加すると、プレースホルダーが空でない文字列に展開される場合に限り、展開の直前にスペースが挿入されます。

tformat:

tformat: 形式は、 "separator" セマンティクスの代わりに "terminator" セマンティクスを提供することを除いて、 format: とまったく同じように機能します。つまり、各コミットには、エントリ間に区切り文字を配置するのではなく、メッセージターミネータ文字(通常は改行)が追加されます。これは、「1行」形式と同様に、1行形式の最終エントリが新しい行で適切に終了することを意味します。例えば:
```
$ 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: があるかのように解釈(interpret)されます。たとえば、以下の2つは同等です:
```
$ git log -2 --pretty=tformat:%h 4da45bef
$ git log -2 --pretty=%h 4da45bef
```

DIFF FORMATTING

デフォルトでは、 git log はdiff出力を生成しません。以下のオプションを使用して、各コミットによって行われた変更を表示できます。

注意: --diff-merges のバリエーション(短い -m、 -c、 --cc オプションを含む)の1つが明示的に指定されていない限り、マージコミットはdiffを表示しませんし、--patch`のようなdiff書式が選択されていても、-S`のような検索オプションと一致しません。例外は、`--first-parent`が使用されている場合です。この場合、`first-parent`がデフォルトの書式です。

-p

-u

--patch

パッチを生成します(generating patches に関するセクションを参照)。

-s

--no-patch

diff出力を抑制します。デフォルトでパッチを表示する git show のようなコマンド、または --patch の効果をキャンセルする場合に便利です。

--diff-merges=(off|none|on|first-parent|1|separate|m|combined|c|dense-combined|cc|remerge|r)

--no-diff-merges

マージコミットに使用するdiff形式を指定します。 --first-parent が使用されている場合を除き、デフォルトは off です。使用されている場合は、 first-parent がデフォルトです。

--diff-merges=(off|none)
--no-diff-merges: マージコミットのdiffの出力を無効にします。暗黙の値を上書きするのに便利です。
--diff-merges=on
--diff-merges=m
-m: このオプションにより、マージコミットのdiff出力がデフォルトの形式で表示されます。 -m は、 -p も指定されている場合にのみ出力を生成します。デフォルトの形式は、 log.diffMerges 構成パラメーター(configuration parameter)を使用して変更できます。デフォルト値は separate です。
--diff-merges=first-parent
--diff-merges=1: このオプションにより、マージコミットは最初の親に関してのみ完全なdiffを表示します。
--diff-merges=separate: これにより、マージコミットは各親に関して完全なdiffを表示します。親ごとに個別のログエントリとdiffが生成されます。
--diff-merges=remerge
--diff-merges=r
--remerge-diff: このオプションを使用すると、2 つの親マージ・コミットが再マージされて、一時的なツリー・オブジェクトが作成されます。 — これには、競合マーカーなどを含むファイルが含まれる可能性があります。次に、その一時ツリーと実際のマージ・コミットの間の差分が表示されます。

このオプションが使用されたときの出力は変更される可能性があり、他のオプションとの相互作用も変更される可能性があります (明示的に文書化されていない限り)。
--diff-merges=combined
--diff-merges=c
-c: このオプションを使用すると、マージコミットのdiff出力は、親と結果のペアごとの差分を一度に1つずつ表示するのではなく、各親からの差分をマージ結果に同時に表示します。さらに、すべての親から変更されたファイルのみが一覧表示されます。 -c は -p の機能を含んでいます。
--diff-merges=dense-combined
--diff-merges=cc
--cc: このオプションを使用すると、 --diff-merges=Combined によって生成される出力は、親のコンテンツに2つの派生(variants)しかない、興味のないハンクを省略してさらに圧縮され、マージ結果は変更なしでそのうちの1つを選択します。 --cc は -p の機能を含んでいます。

--combined-all-paths

このフラグにより、結合された差分(マージコミットに使用)にすべての親からのファイルの名前が一覧表示されます。したがって、これは --diff-merges=[dense-]combined が使用されている場合にのみ有効であり、ファイル名の変更が検出された場合(つまり、名前の変更またはコピーの検出が要求された場合)にのみ役立つ可能性があります。

-U<n>

--unified=<n>

通常の3行ではなく、<n> 行の内容でdiffを生成します。 --patch の機能を含んでいます。

--output=<file>

stdout ではなく指定のファイルに出力します。

--output-indicator-new=<char>

--output-indicator-old=<char>

--output-indicator-context=<char>

生成されたパッチの新しい行、古い行、またはコンテキスト行を示すために使用される文字を指定します。通常、それらはそれぞれ "+"、 "-"、 " " です。

--raw

コミットごとに、生の差分形式を使用して変更の概要を表示します。 git-diff(1) の "RAW OUTPUT FORMAT" セクションを参照してください。これは、ログ自体をraw形式で表示することとは異なります。これは --format=raw で実現できます。

--patch-with-raw

-p --raw の同義語。

-t

diff出力にツリーオブジェクトを表示します。

--indent-heuristic

diffハンクの境界をずらす(shift)ヒューリスティックを有効にして、パッチを読みやすくします。これがデフォルトです。

--no-indent-heuristic

インデントヒューリスティック(indent heuristic)を無効にします。

--minimal

より多くの時間を費やして、可能な限り最小のdiffが生成されるようにします。

--patience

"patience diff" アルゴリズムを使用してdiffを生成します。

--histogram

"histogram diff" アルゴリズムを使用してdiffを生成します。

--anchored=<text>

"anchored diff" アルゴリズムを使用してdiffを生成します。

このオプションは複数回指定できます。

行がソースと宛先の両方に存在し、1回だけ存在し、このテキストで始まる場合、このアルゴリズムは、その行が出力に削除または追加として表示されないようにします。内部で "patience diff" アルゴリズムを使用します。

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

diffアルゴリズムを選択します。その派生(variants)は以下のとおりです:

default, myers: 基本的な貪欲な差分アルゴリズム(greedy diff algorithm)。現在、これがデフォルトです。
minimal: より多くの時間を費やして、可能な限り最小のdiffが生成されるようにします。
patience: パッチを生成する時に "patience diff" アルゴリズムを使います。
histogram: このアルゴリズムは、忍耐アルゴリズム(patience algorithm)を拡張して、「発生率の低い共通要素をサポート」(support low-occurrence common elements)します。

たとえば、あなたが diff.algorithm 変数をデフォルト以外の値に設定した上で、それでもデフォルト値を使用する場合は、--diff-algorithm=default オプションを使用する必要があります。

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

diffstatを生成します。デフォルトでは、必要なだけのスペースがファイル名部分に使用され、残りはグラフ部分に使用されます。最大幅はデフォルトで端末幅、または端末に接続されていない場合は80桁であり、 <width> で上書きできます。ファイル名部分の幅は、コンマの後に別の幅 <name-width> を指定することで制限できます。グラフ部分の幅は、 --stat-graph-width=<width> (統計グラフを生成するすべてのコマンドに影響します)を使用するか、 diff.statGraphWidth=<width> ( git format-patch に影響しません)を設定することによって制限できます。3番目のパラメータ <count> を指定することにより、出力を最初の <count> 行に制限し、それに ... が続く形にできます。

これらのパラメータは、 --stat-width=<width> と --stat-name-width=<name-width> と --stat-count=<count> を使用して個別に設定することもできます。

--compact-summary

ファイルの作成や削除( "new" または "gone" 。オプションでシンボリックリンクの場合は "+l" )、diffstatのモード変更(実行可能ビットを追加または削除する場合は、それぞれ "+x" または "-x" )など、拡張ヘッダー情報の要約を出力します。情報はファイル名部分とグラフ部分の間に置かれます。本機能は --stat の機能を含んでいます。

--numstat

--stat に似ていますが、プログラムで処理しやすい(machine friendly)ように、追加および削除された行数を10進表記とパス名で省略形なしで表示します。バイナリファイルの場合、 0 0 の代わりに2つの - を出力します。

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

作成、名前変更、モード変更などの拡張ヘッダー情報の短い要約(condensed summary)を出力します。

--patch-with-stat

-p --stat と同義語。

-z

改行(newline)ではなく、NULでコミットを区切ります。

また、 --raw または --numstat を指定した場合は、パス名を難読化(munge)したり、出力フィールドターミネータとしてNULを使用したりしないでください。

このオプションがないと、構成変数 core.quotePath で説明されているように、通常の文字以外(unusual characters)を含むパス名が引用符で囲まれます(git-config(1) 参照)。

--name-only

変更されたファイルの名前のみを表示します。多くの場合、ファイル名はUTF-8でエンコードされます。詳細については、 git-log(1) のマニュアルページにあるエンコーディングに関する議論(the discussion about encoding)を参照してください。

--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を示します。configオプションが設定されていない場合、デフォルトは diff.submodule または short 形式です。

--color[=<when>]

色付きのdiffを表示します。 --color (つまり、 =<when> 無し) は --color=always と同じです。 <when> は、 always または never または auto のいずれかになります。

--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 色のいずれかを使用して色付けされます。2つの色の間の変化は、新しいブロックが検出されたことを示します。
dimmed-zebra: zebra に似ていますが、移動されたコードの重要でない部分の追加の調光(dimmed)が実行されます。隣接する2つのブロックの境界線は興味深いと見なされ、残りは興味深いものではありません。 dimmed_zebra は非推奨の同義語です。

--no-color-moved

移動検出をオフにします。これは、構成設定を上書きするために使用できます。 --color-moved=no と同じです。

--color-moved-ws=<modes>

これは、 --color-moved の移動検出を実行するときに空白を無視する方法を設定します。これらのモードは、コンマ区切りのリストとして指定できます:

no: 移動行検出を実行するときに、空白(whitespace)を無視しない。
ignore-space-at-eol: 行末(EOL)での空白(whitespace)の変更を無視します。
ignore-space-change: 空白(whitespace)の数の変更は無視してください。これは、行末の空白(whitespace)を無視し、1つ以上の空白文字(whitespace characters)の他のすべてのシーケンスを同等と見なします。
ignore-all-space: 行を比較するときは空白(whitespace)を無視します。これにより、一方の行に空白があり、もう一方の行に空白がない場合でも、違いは無視されます。
allow-indentation-change: 最初に移動検出で空白(whitespace)を無視し、空白(whitespace)の変更が行ごとに同じである場合にのみ、移動されたコードブロックをブロックにグループ化します。これは他のモードと互換性がありません。

--no-color-moved-ws

移動検出を実行するときは、空白(whitespace)を無視しないでください。これは、構成設定を上書きするために使用できます。 --color-moved-ws=no と同じです。

--word-diff[=<mode>]

<mode> を使用して変更された単語を区切ることにより、単語のdiffを表示します。デフォルトでは、単語は空白で区切られます。以下の --word-diff-regex を参照してください。 <mode> のデフォルトは plain です。 <mode> は以下のいずれかである必要があります:

color: 変更された単語(word)を色のみを使用して強調表示します。 --color を意味します。
plain: 単語を [-removed-] および {+added+} として表示します。区切り文字が入力に表示されている場合、区切り文字をエスケープしようとしないため、出力があいまいになる可能性があります。
porcelain: スクリプトの使用を目的とした特別な行ベースの形式を使用します。追加/削除/無変更については、通常の統一されたdiff形式で印刷され、行の先頭の +/-/` ` 文字で始まり、行の終わりまで続きます。入力の改行は、それ自体の行のチルダ ~ で表されます。
none: 単語(word)のdiffを再度無効にします。

注意: 最初のモードの名前にもかかわらず、有効になっている場合、すべてのモードで変更された部分を強調するために色が使用されることに注意してください。

--word-diff-regex=<regex>

空白以外を単語と見なす代わりに、 <regex> を使用して単語が何であるかを決定します。また、すでに有効になっていない限り、この機能は --word-diff の機能を含んでいます。

<regex> の重複しないマッチはすべて、単語と見なされます。これらのマッチの間のすべては空白と見なされ、違いを見つけるためとしては無視されます！正規表現に |[^[:space:]] を追加して、空白以外のすべての文字とマッチすることを確認することをお勧めします。改行を含むマッチは、改行で黙って切り捨てられます！

たとえば、 --word-diff-regex=. は各文字を単語として扱い、それに応じて文字ごとの違いを表示します。

正規表現は、diffドライバーまたは構成オプション(configuration option)を介して設定することもできます。 gitattributes(5) または git-config(1) を参照してください。これを指定すると、diffドライバーまたは構成設定(configuration settings)が明示的にオーバーライドされます。diffドライバーは構成設定を上書きします。

--color-words[=<regex>]

--word-diff=color に --word-diff-regex=<regex> を加えたものに相当します(正規表現が指定されている場合)。

--no-renames

構成ファイルにデフォルトで指定されている場合でも、名前変更の検出をオフにします。

--[no-]rename-empty

名前変更ソースとして空のブロブを使用するかどうか。

--check

変更によって競合マーカーまたは空白エラーが発生した場合に警告します。空白エラーと見なされるものは、 core.whitespace 構成によって制御されます。デフォルトでは、末尾の空白(空白のみで構成される行を含む)と、行の最初のインデント内で直後にタブ文字が続くスペース文字は、空白エラーと見なされます。問題が見つかった場合は、ゼロ以外のステータスで終了します。なお、 --exit-code とは互換性がありません。

--ws-error-highlight=<kind>

diffの context または old または new 行の空白エラーを強調表示します。複数の値はコンマで区切られ、 none は前の値をリセットし、 default はリストを new にリセットし、 all は old、new、context の省略形です。このオプションが指定されておらず、構成変数 diff.wsErrorHighlight が設定されていない場合、 new 行の空白エラーのみが強調表示されます。空白エラーは color.diff.whitespace で色分けされています。

--full-index

パッチ形式の出力を生成するときは、最初の一握りの文字(first handful of characters)の代わりに、「インデックス」行にイメージ前およびイメージ後の完全ブロブオブジェクト名を表示します。

--binary

--full-index に加えて、 git-apply で適用できるバイナリ差分を出力します。 --patch の機能を含んでいます。

--abbrev[=<n>]

完全な40バイトの16進オブジェクト名をdiff-raw形式の出力とdiff-treeヘッダー行に表示する代わりに、オブジェクトを一意に参照する、少なくとも <n> 桁の16進数の長さの最短のプレフィックスを表示します。diffパッチ出力形式では、 --full-index が優先されます。つまり、 --full-index が指定されている場合、 --abbrev に関係なく、完全なブロブ名が表示されます。デフォルト以外の桁数は、 --abbrev=<n> で指定できます。

-B[<n>][/<m>]

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

完全な書き換えの変更を削除と作成のペアに分割します。これには以下の2つの目的があります:

これは、ファイルの完全な書き換えに相当する変更が、コンテキストとしてテキストで一致する非常に少数の行と混合された一連の削除と挿入としてではなく、古いものすべての単一の削除とそれに続くすべての新しいものを1回挿入し、数値 m が -B オプションのこの側面を制御します(デフォルトは60%)。 -B/70% は、Gitがそれを完全な書き換えと見なすために、元の30%未満が結果に残る必要があることを指定します(つまり、結果のパッチは、コンテキスト行と混合された一連の削除と挿入になります)。

-M と一緒に使用すると、完全に書き換えられたファイルも名前変更のソースと見なされ(通常、 -M は、消えたファイルのみを名前変更のソースと見なします)、数 n が -Bオプションのこの側面を制御します(デフォルトは50%)。 -B20% は、ファイルのサイズの20%以上と比較して、追加および削除を伴う変更が、別のファイルへの名前変更の可能なソースとして取得される資格があることを指定します。

-M[<n>]

--find-renames[=<n>]

diffを生成する場合は、コミットごとに名前の変更を検出して報告します。履歴をトラバースしながら名前を変更してファイルをフォローする方法については、 --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 オプションは、コピーの元のファイルが同じ変更組(changeset)で変更された場合にのみコピーを検索します。このフラグにより、コマンドは変更されていないファイルをコピー元の候補として検査します。これは大規模なプロジェクトでは非常にコストのかかる操作であるため、注意して使用してください。複数の -C オプションを指定しても同じ効果があります。

-D

--irreversible-delete

削除するプレイメージ(preimage)を省略します。つまり、ヘッダーのみを出力し、プレイメージと /dev/null の差分は出力しません。結果のパッチは、 patch または git apply で適用されることを意図していません。これは、変更後にテキストを確認することに集中したい人のためだけのものです。さらに、出力には明らかに、そのようなパッチを手動でも逆に適用するのに十分な情報が不足しているため、オプションの名前が付けられています。

-B と併用する場合は、削除/作成ペアの削除部分のプリイメージ(preimage)も省略してください。

-l<num>

-M および -C オプションには、名前変更/コピーのサブセットを安価に検出できるいくつかの準備手順が含まれ、その後に、残りのすべてのペアになっていない宛先をすべての関連ソースと比較する徹底的なフォールバック部分が続きます。(名前の変更の場合、残りのペアになっていないソースのみが関係します。コピーの場合、すべての元のソースが関係します)。Nのソースと宛先の場合、この徹底的なチェックのコストは O(N^2) です。このオプションは、関係するソース/宛先ファイルの数が指定された数を超えた場合に、名前変更/コピー検出の完全な部分が実行されないようにします。デフォルトは diff.renameLimit です。値0は無制限として扱われることに注意してください。

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

追加(Add)・コピー(Copy)・削除(Delete)・変更(Modify)・名前変更(Rename)されたファイル、タイプが変更されたファイル(T)、マージされていないファイル(U)、不明なファイル(X)、またはペアリングが壊れているファイル(B)のみを選択します。フィルタ文字(無しも含む)の任意の組み合わせを使用できます。組み合わせに * (全てまたは無し)が追加されると、比較で他の基準に一致するファイルがある場合、すべてのパスが選択されます。他の基準に一致するファイルがない場合、何も選択されません。

また、逆に、除外したい時はこれらの各大文字指定を小文字にして指定します。例えば --diff-filter=ad は、追加および削除されたパスを除外します。

注意:すべてのdiffがすべてのタイプを特徴とするわけではないことに注意してください。たとえば、これらのタイプの検出(detection)が無効になっている場合、コピーされたエントリと名前変更されたエントリは表示されません。

-S<string>

ファイル内の指定の文字列(つまり、 addition 、deletion)の出現回数の差分を調べます。スクリプターが使用することを目的としています。

(構造体など)コードの正確なブロックを探していて、そのブロックが最初に作成されてからの履歴を知りたい場合に便利です。この機能を繰り返し使用して、プリイメージ(preimage)内の興味深いブロックを -S にフィードバックし、そしてあなたはそれをブロックの最初のバージョンを取得するまで続けます。

バイナリファイルも検索されます。

-G<regex>

パッチテキストに <regex> にマッチする追加/削除された行が含まれている差分を探します。

-S<regex> --pickaxe-regex と -G<regex> の違いを説明するために、同じファイル内で以下のdiffを使用してコミットすることを検討してください:

+    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を検索します。

オブジェクトは、ブロブまたはサブモジュールのコミットにすることができます。これは、 git-log の -t オプションがツリーも探すことを意味します。

--pickaxe-all

-S または -G が変更を見つけたら、 <string> の変更を含むファイルだけでなく、その変更セット(changeset)のすべての変更を表示します。

--pickaxe-regex

-S に指定した <string> を拡張POSIX正規表現として扱います。

-O<orderfile>

ファイルが出力に表示される順序を制御します。これは diff.orderFile 構成変数をオーバーライドします(git-config(1) 参照)。 diff.orderFile をキャンセルするには、 -O/dev/null を使用します。

出力順序は、 <orderfile> 内のglobパターンの順序によって決定されます。最初のパターンに一致するパス名を持つすべてのファイルが最初に出力され、2番目のパターンに一致する(ただし最初のパターンには一致しない)パス名を持つすべてのファイルが次に出力されます。パス名がどのパターンとも一致しないすべてのファイルは、ファイルの最後に暗黙のすべて一致パターンがあるかのように、最後に出力されます。複数のパス名のランクが同じである場合(同じパターンに一致するが、以前のパターンには一致しない)、相互の出力順序は通常の順序です。

<orderfile> は以下のとおりパースされます:

空白行は無視されるため、読みやすくするための区切りとして使用できます。
ハッシュ ("#") で始まる行は無視されるため、コメントに使用できます。パターンがハッシュで始まる場合は、パターンの先頭にバックスラッシュ(訳注:日本では環境により円記号)("\") を追加します。
他の各行には、単一のパターンが含まれています。

パターンは、 FNM_PATHNAME フラグなしで fnmatch(3) に使用されるパターンと同じ構文とセマンティクスを持ちますが、最終的なパス名コンポーネントをいくつも削除するとパターンと一致する場合、パス名もパターンと一致する点が異なります。たとえば、パターン "foo*bar" は、 "fooasdfbar" および "foo/bar/baz/asdf" と一致しますが、 "foobarx" とは一致しません。

--skip-to=<file>

--rotate-to=<file>

名前付き <file> の前のファイルを出力から破棄するか(スキップして)、出力の最後に移動させます(ローテーションさせます)。これらは主に git difftool コマンドを使用するために考案されたものであり、それ以外の場合はあまり役に立たない可能性があります。

-R

2つの入力を交換します。つまり、インデックスまたはディスク上のファイルとツリーの内容の違いを表示します。

--relative[=<path>]

--no-relative

プロジェクトのサブディレクトリから実行する場合、このオプションを使用して、ディレクトリ外の変更を除外し、それに関連するパス名を表示するように指示できます。サブディレクトリ(ベアリポジトリなど)にいない場合は、引数として <path> を指定することで、出力を作成するサブディレクトリに名前を付けることができます。 --no-relative`は、 `diff.relative 設定オプションと以前の --relative の両方を打ち消すために使用できます。

-a

--text

すべてのファイルをテキストとして扱います。

--ignore-cr-at-eol

比較を行うときは、行末のキャリッジリターン(carriage-return)を無視します。

--ignore-space-at-eol

行末(EOL)での空白(whitespace)の変更を無視します。

-b

--ignore-space-change

空白(whitespace)の数の変更は無視してください。これは、行末の空白(whitespace)を無視し、1つ以上の空白文字(whitespace characters)の他のすべてのシーケンスを同等と見なします。

-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) の「Defining a custom hunk-header」参照)。

--ext-diff

外部diffヘルパーの実行を許可します。 gitattributes(5) を使用して外部diffドライバーを設定する場合は、 git-log(1) およびその仲間と一緒にこのオプションを使用する必要があります。

--no-ext-diff

外部diffドライバーを禁止します。

--textconv

--no-textconv

バイナリファイルを比較するときに、外部テキスト変換フィルターの実行を許可(または禁止)します。詳細については、 gitattributes(5) を参照してください。textconvフィルターは通常、一方向の変換であるため、結果のdiffは人間の消費に適していますが、適用(apply)することはできません。このため、textconvフィルターは、 git-diff(1) および git-log(1) に対してのみデフォルトで有効になりますが、 git-format-patch(1) またはdiff配管コマンドに対しては有効になりません。

--ignore-submodules[=<when>]

diff生成のサブモジュールへの変更を無視します。 <when> は、 none・untracked・dirty・allのいずれかになります。これがデフォルトです。noneを使用すると、追跡されていないファイルまたは変更されたファイルが含まれている場合、またはそのHEADがスーパープロジェクトに記録されているコミットと異なる場合にサブモジュールが変更されたと見なされ、 git-config(1) または gitmodules(5) の ignoreオプションの設定をオーバーライドするために使用できます。untrackedが使用されている場合、サブモジュールには追跡されていないコンテンツのみが含まれている場合、サブモジュールはダーティとは見なされません(ただし、変更されたコンテンツはスキャンされます)。「dirty」を使用すると、サブモジュールの作業ツリーへのすべての変更が無視され、スーパープロジェクトに格納されているコミットへの変更のみが表示されます(これは1.7.0までの動作でした)。「all」を使用すると、サブモジュールへのすべての変更が非表示になります。

--src-prefix=<prefix>

"a/" の代わりに、与えられたソースプレフィックス(source prefix)を表示します。

--dst-prefix=<prefix>

"b/" の代わりに、指定された宛先プレフィックス(destination prefix)を表示します。

--no-prefix

送信元(source)または宛先(destination)のプレフィックスを表示しません。

--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) も参照してください。

Generating patch text with -p

git-diff(1) 、 git-log(1) 、 git-show(1) 、 git-diff-index(1) 、 git-diff-tree(1) 、 git-diff-files(1) に -p オプションを付けて実行するとパッチテキストを生成します。パッチテキストの作成は、 GIT_EXTERNAL_DIFF と GIT_DIFF_OPTS 環境変数( git(1) 参照)、および diff 属性( gitattributes(5) 参照)を介してカスタマイズできます。

-pオプションが生成するものは、従来のdiff形式とは少々異なります:

先行して、以下のような "git diff" ヘッダーがあります:
```
diff --git a/file1 b/file2
```
名前の変更/コピーが含まれない限り、 a/ と b/ のファイル名は同じです。特に、作成または削除の場合でも、 a/ または b/ ファイル名の代わりに /dev/ null が使用されることはありません。

名前変更/コピーが含まれる場合、 file1 と`file2` は、それぞれ名前変更/コピーのソースファイルの名前と、名前変更/コピーが生成するファイルの名前を示します。
その後に、1つ以上の拡張ヘッダー行達が続きます:
```
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桁の8進数として出力されます。

拡張ヘッダーのパス名には、 a/ および b/ プレフィックスは含まれません。

類似インデックス(similarity index)は変更されていない行のパーセンテージであり、非類似インデックス(dissimilarity index)は変更された行のパーセンテージです。これは切り捨てられた整数であり、その後にパーセント記号が続きます。したがって、100％の類似インデックス値は2つの等しいファイルを表し、100％の非類似性は古いファイルから新しいファイルに移行された行がないことを意味します。

インデックス行には、変更前後のブロブオブジェクト名が含まれます。 <mode> は、ファイルモードが変更されない場合に含まれます。それ以外の場合、別々の行は古いモードと新しいモードを示します。
通常の文字でないキャラクタ(\"unusual\" characters)を含むパス名は、構成変数 core.quotePath で説明されているように引用符で囲まれています( git-config(1)参照)。
出力内のすべての 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
```
ハンクのヘッダーには、ハンクが適用される関数の名前が記載されています。特定の言語に合わせてこれを調整する方法の詳細については、 gitattributes(5) の "Defining a custom hunk-header" を参照してください。

Combined diff format

diffを生成するコマンドは、マージを表示するときに -c または --cc オプションを使用して「合成diff」(combined diff)を生成できます。これは git-diff(1) または git-show(1) でのマージを表示するときのデフォルトの形式です。注意: これらのコマンドのいずれかに適切な --diff-merges オプションを指定して、特定の形式で差分を強制的に生成できることにも注意してください。

合成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 オプションが使用されている場合):
```
diff --combined file
```
または、以下のようになります( --cc オプションが使用されている場合):
```
diff --cc file
```
その後に1つ以上の拡張ヘッダー行が続きます(以下の例は、2つの親とのマージを示しています):
```
index <hash>,<hash>..<hash>
mode <mode>,<mode>..<mode>
new file mode <mode>
deleted file mode <mode>,<mode>
```
mode <mode>,<mode>..<mode> 行は、<mode> の少なくとも1つが他の <mode> と異なる場合にのみ表示されます。検出されたコンテンツの移動(名前の変更とコピーの検出)に関する情報を含む拡張ヘッダーは、2つの <tree-ish> のdiffで機能するように設計されており、合成diff形式では使用されません。
その後に2行の from-file/to-file ヘッダーが続きます
```
--- a/file
+++ b/file
```
従来の統一diff形式の2行ヘッダーと同様に、 /dev/null は、作成または削除されたファイルを通知するために使用されます。

ただし、 --combined-all-paths オプションが指定されている場合、2行の from-file/to-file の代わりに、 N+1 行の from-file/to-file ヘッダーが取得されます。ここで、 N はマージコミットの親の数です。
```
--- a/file
--- a/file
--- a/file
+++ b/file
```
この拡張形式は、名前変更またはコピー検出がアクティブな場合に役立ち、別の親のファイルの元の名前を確認できます。
チャンクヘッダーの形式が変更され、誤って patch-p1 にフィードされるのを防ぎます。合成差分形式は、マージコミットの変更を確認するために作成されたものであり、適用されることを意図したものではありません。この変更は、拡張された「インデックス」ヘッダーの変更に似ています:
```
@@@ <from-file-range> <from-file-range> <to-file-range> @@@
```
合成diff形式のチャンクヘッダーには親の数+1の @ 文字があります。

従来の統一diff形式とは異なり、2つのファイルAとBが、 - (マイナスはAに表示されますが、Bでは削除されます) または + (プラスはAにはありませんが、Bには追加されます)、または " "（スペースは変更なし) プレフィックスを持つ単一の列で表示される場合、この形式は2つ以上のファイル file1, file2,… を1つのファイルXと比較し、Xが各 fileN とどのように異なるかを示します。ファイルNごとに1つの列が出力行の前に追加され、Xの行が出力行とどのように異なるかを示します。

列Nの - 文字は、その行が fileN に表示されているが、結果には表示されていないことを意味します。列Nの + 文字は、結果に行が表示され、 fileN にその行がないことを意味します(つまり、その親の観点から見て行が追加されたことを示す)。

上記の出力例では、関数のシグネチャが両方のファイルから見て変更されています(したがって、 file1 と file2 の両方から2つの - が削除され、さらに ++ が追加されたため、 file1 と file2 のどちらにも表示されません)。また、他の8行は file1 と同じですが、 file2 には表示されません(したがって、接頭辞として + が付けられます)。

git diff-tree -c で表示される場合、マージコミットの親をマージ結果と比較します(つまり、 file1..fileN が親です)。 git diff-files -c で表示される場合、2つの未解決のマージ親を作業ツリーファイルと比較します(つまり、 file1 はステージ2、別名「私たちのバージョン」、 file2 はステージ3、別名「彼らのバージョン」です)。

EXAMPLES

git log --no-merges: コミット履歴全体を表示しますが、マージはスキップします
git log v2.6.12.. include/scsi drivers/scsi: バージョン v2.6.12 以降で include/scsi または drivers/scsi サブディレクトリ内のファイルの変更がある、すべてのコミットを表示します
git log --since="2 weeks ago" -- gitk: gitk ファイルの変更について過去2週間の範囲で表示します。 -- は「ブランチ名の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個に制限します。

DISCUSSION

Gitは、ある程度までは文字エンコードに依存しません。

ブロブオブジェクトの内容は、解釈されていないバイトのシーケンスです。コアレベルでのエンコーディング変換はありません。
パス名はUTF-8正規化形式C(UTF-8 normalization form 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はそれを禁止しません。ただし、覚えておくべきことがいくつかあります。

git commit と git commit-tree は、プロジェクトがレガシーエンコーディングを使用していることを明示的に指定しない限り、与えられたコミットログメッセージが有効なUTF-8文字列のように見えない場合に警告を発します。明示的に指定する方法は、以下のように、 .git/config ファイルに i18n.commitEncoding を含めることです。
```
[i18n]
        commitEncoding = ISO-8859-1
```
上記の設定で作成されたコミットオブジェクトは、 encoding ヘッダーに i18n.commitEncoding の値を記録します。これは、後でそれらを見る他の人々を助けるためです。このヘッダーがないということは、コミットログメッセージがUTF-8でエンコードされていることを意味します。
git log や git show や git blame とその仲間たちは、コミットオブジェクトの encoding ヘッダーを見て、特に指定がない限り、ログメッセージをUTF-8に再コーディングしようとします。あなたは以下のように、 .git/config ファイルの i18n.logOutputEncoding を使用して目的の出力エンコーディングを指定できます。
```
[i18n]
        logOutputEncoding = ISO-8859-1
```
この構成変数がない場合は、代わりに i18n.commitEncoding の値が使用されます。

UTF-8への再コーディングは必ずしも可逆的な操作ではないため、我々はコミットが行われたときにコミットログメッセージを再コーディングしないことを意図的に選択したことに注意してください。

CONFIGURATION

コア変数については git-config(1) を、diff生成に関連する設定については git-diff(1) を参照してください。

format.pretty: --format オプションのデフォルト。(上記「Pretty Formats」を参照してください。)デフォルトは medium です。
i18n.logOutputEncoding: ログを表示するときに使用するエンコーディング。(上記「Discussion」を参照してください。)デフォルトでは、設定されている場合は i18n.commitEncoding の値になり、そうでない場合は UTF-8 になります。

このセクションのこの行より上にあるものはすべて、 git-config(1) ドキュメントには含まれていません。以下の内容に関しては、git-config(1) ドキュメントにあるものと同一です。

log.abbrevCommit: trueの場合、 linkgit: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コマンドで表示されるコミットのref名を出力します。 short が指定されている場合、ref名の接頭辞 refs/heads/ と refs/tags/ と refs/remotes/ は出力されません。 full が指定されている場合、完全なref名(接頭辞を含む)が出力されます。 auto が指定されている場合、出力が端末に送られる場合、ref名は short が指定されているかのように表示されます。それ以外の場合、ref名は表示されません。これは、 git log の --decorate オプションと同じです。
log.initialDecorationSet: デフォルトでは、 git log は特定の既知の ref 名前空間の装飾(decorations)のみを表示します。 all が指定されている場合は、すべてのrefを装飾として表示します。
log.excludeDecoration: ログ装飾(log decorations)から指定されたパターンを除外します。これは --decorate-refs-exclude コマンドラインオプションに似ていますが、構成オプションは --decorate-refs オプションで上書きできます。
log.diffMerges: マージコミットに使用されるデフォルトのdiff形式を設定します。詳細については、 git-log(1) の --diff-merges を参照してください。デフォルトは separate です。
log.follow: true の場合、 git log は、単一の<path>が指定されたときに --follow オプションが使用されたかのように機能します。これには --follow と同じ制限があります。つまり、複数のファイルを追跡するために使用することはできず、非線形履歴ではうまく機能しません。
log.graphColors: git log --graph で履歴線(history lines)を描画するために使用できる、コンマで区切られた色のリスト。
log.showRoot: trueの場合、最初のコミットは大きな作成イベントとして表示されます。これは、空のツリーに対するdiffに相当します。 git-log(1) や git-whatchanged(1) などのツールは、通常はルートコミットを隠していますが、今後は表示されるようになります。デフォルトでは 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: ノートの競合を解決するときにデフォルトで選択するマージ戦略。 manual 、` ours`、 theirs、` union` 、cat_sort_uniq のいずれかである必要があります。デフォルトは manual です。各戦略の詳細については、 git-notes(1) の「NOTES MERGE STRATEGIES」セクションを参照してください。

この設定は、 --strategy オプションを git-notes(1) に渡すことでオーバーライドできます。
notes.<name>.mergeStrategy: refs/notes/<name> にノートをマージするときに、どのマージ戦略を選択するか。これは、より一般的な notes.mergeStrategy をオーバーライドします。利用可能な戦略の詳細については、 git-notes(1) の「NOTES MERGE STRATEGIES」セクションを参照してください。
notes.displayRef: git log 系のコマンドでコミット・メッセージを表示する際に、 core.notesRef や GIT_NOTES_REF で設定したデフォルトに加えて、どのref (グロブ、または複数回指定されている場合は複数ref)からノートを読み込むかを指定します。

この設定は、 GIT_NOTES_DISPLAY_REF 環境変数でオーバーライドでき、環境変数はコロンで区切られたrefまたはグロブ(glob)のリストである必要があります。

存在しないrefsに対しては警告が発行されますが、どのrefsにもマッチしないグロブは黙って無視されます。

この設定は、コマンドの git log 系の --no-notes オプション、またはこれらのコマンドで受け入れられる --notes=<ref> オプションによって無効にすることができます。

core.notesRef の有効な値(GIT_NOTES_REFによってオーバーライドされる可能性があります)も、表示されるrefのリストに暗黙的に追加されます。
notes.rewrite.<command>: <command> (現在は amend または rebase)でコミットを書き換え、そして、この変数が false に設定されている場合、git はノートを元のコミットから書き換えられたコミットにコピーしません。デフォルトは true です。下記 notes.rewriteRef も参照してください。

この設定は、 GIT_NOTES_REWRITE_REF 環境変数でオーバーライドでき、環境変数はコロンで区切られたrefまたはグロブ(glob)のリストである必要があります。
notes.rewriteMode: 書き換え時にノートをコピーする場合(notes.rewrite.<command> オプション参照)、ターゲットコミットにすでにノートがある場合の対処方法を決定します。 overwrite 、 concatenate 、 cat_sort_uniq 、 ignore のいずれかである必要があります。デフォルトは concatenate です。

この設定は、 GIT_NOTES_REWRITE_MODE 環境変数でオーバーライドできます。
notes.rewriteRef: 書き換え中にノートをコピーする場合は、ノートをコピーする(完全修飾された)refを指定します。グロブと見なしたら、マッチするすべてのrefのノートがコピーされます。この構成を複数回指定することもできます。

デフォルト値はありません。ノートの書き換えを有効にするには、この変数を構成する必要があります。デフォルトのコミットノートの書き換えを有効にするには、これを refs/notes/commits に設定します。

GIT_NOTES_REWRITE_REF 環境変数でオーバーライドできます。その形式の詳細については、上記 notes.rewrite.<command> を参照してください。

GIT

Part of the git(1) suite

git-log(1) Manual Page

NAME