git-log

Contents

コマンド名

「git-log」:コミットログを表示

概要

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

説明

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

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

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

したがって、次のようなコマンドとなります。

$ git log foo bar ^baz

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

「^ <commit1> <commit2>」の省略形として、特別な表記「<commit1> .. <commit2>」を使用できます。例えば、次のいずれかを同じ意味で使用できます。

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

もう1つの特別な表記法としてはマージに役立つ「<commit1>…<commit2>」です。結果として得られるコミットのセットは2つのオペランド間の差となります。次の2つのコマンドは同等です。

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

表示されているコミットの参照名を出力します。「short」が指定されている場合、参照名の接頭辞「refs / heads /、refs / tags /」、および「refs / remotes /」は出力されません。「full」が指定されている場合、完全な参照名(プレフィックスを含む)が出力されます。「auto」が指定されている場合、出力が末端に送付されると、参照名は「short」が指定されているかのように表示されます。それ以外の場合、参照名は表示されません。デフォルトのオプションは「short」です。

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

--decorate-refs が指定されていない場合、すべての参照が含まれているように見せます。候補ごとに--decorate-refs-excludeに指定されたパターンのいずれにも一致する場合、または--decorate-refsに指定されたパターンのいずれにも一致しない場合、デコレーションに使用しないでください。log.excludeDecoration構成オプションを使用すると、デコレーションから参照を除外できますが、明示的な--decorate-refsパターンはlog.excludeDecorationの一致を上書きします。

--source

各コミットに到達したコマンドラインで指定された参照名を出力します。

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

メールマップファイルを使用して、作成者とコミッターの名前と電子メールアドレスを正規の本名と電子メールアドレスにマップします。git-shortlog[1]を参照してください。

--full-diff

このフラグがない場合、git log -p <path>... は指定されたパスに接触するコミットを示し、同じ指定されたパスについて差分を取ります。これにより指定されたパスに接触するコミットの完全な差分が表示されます。 これは「<path>…」がコミットのみを制限し、それらのコミットの差分を制限しないことを意味します。
これはすべての差分ベースの出力タイプに影響することに注意してください。--statなどによって作成されたものです。

--log-size

各コミットの出力に「logsize <number>」というラインを含めます。ここで<number>はそのコミットのメッセージの長さ(バイト単位)となります。事前にスペースを割り当てることを許可することにより、git log出力からログメッセージを読み取るツールを高速化することを目的としています。

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

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

<start>と<end>は次のいずれかのフォーマットを取ることができます。

  • number
    <start>または<end>が数値の場合、絶対ライン数を指定します(ライン数は1から数えます)。
  • /regex/
    このフォームは指定された「POSIX」正規表現に一致する最初のラインを使用します。<start>が正規表現の場合、前の-L範囲の終わりから検索します。そうでない場合、ファイルの先頭から検索します。<start>が「^ / regex /」の場合、ファイルの先頭から検索します。<end>が正規表現の場合、<start>で指定されたラインから検索します。
  • +offset or -offset
    これは<end>に対してのみ有効であり、<start>で指定されたラインの前後のライン数を指定します。

<start>と<end>の代わりに「:<funcname>」を指定すると、<funcname>に一致する最初の「funcname」ラインから次の「funcname」ラインまでの範囲を示す正規表現になります。「:<funcname>」は前の-L 範囲のエンドから検索します。それ以外の場合、ファイルの先頭から検索します。「^:<funcname>」はファイルの先頭から検索します。

<revision range>

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

[--] <path>…

指定されたパスに一致するファイルがどのようになったかを説明するのに十分なコミットのみを表示します。詳細およびその他の簡略化モードについては以下の履歴の簡略化を参照してください。
混乱が生じた場合、パスをオプションまたはリビジョン範囲から分離するために、パスの前に–を付ける必要がある場合があります。

コミット制限

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

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

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

-<number>
-n <number>
--max-count=<number>

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

--skip=<number>

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

--since=<date>
--after=<date>

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

--until=<date>
--before=<date>

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

--author=<pattern>
--committer=<pattern>

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

--grep-reflog=<pattern>

コミット出力を指定されたパターン(正規表現)に一致する参照ログエントリを持つものに制限します。複数の--grep-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が停止します。

--remove-empty

指定されたパスがツリーから消えたら停止します。

--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はすべてのオクトパスマージを提供します。

--no-min-parentsおよび--no-max-parentsはこれらの制限を(制限なしに)再度リセットします。同等のフォーマットは–min-parents=0(コミットには0個以上のペアレントがあります)および--max-parents=-1(負の数は上限がないことを示します)です。

--first-parent

マージコミットを確認したら、最初のペアレントコミットのみを実行します。このオプションを使用すると、特定のトピックブランチの展開を表示する際の概要がわかりやすくなります。これはトピックブランチへのマージは随時更新されるアップストリームに調整するだけである傾向があり、このオプションを使用すると、マージによる履歴において個々のコミットを無視できるためです。

--not

後続のすべてのリビジョンの「^」プレフィックス(またはその欠如)の意味を次の--notまで逆にします。

--all

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

--branches[=<pattern>]

refs/headsにおいてすべての参照が<commit>としてコマンドラインにリスト化されているかのように見せます。<pattern>が指定されている場合、ブランチを指定されたシェルグロブに一致するものに制限します。もしパターンが「 ? 」、「*」、「 [」を含んでいない場合、エンドにある(/*)を意味します。

--tags[=<pattern>]

refs/tags においてすべての参照がコマンドラインに<commit>としてリスト化されているかのように見せます。<pattern>が指定されている場合、指定されたシェルグロブに一致するタグに制限します。もしパターンが「 ? 」、「*」、「 [」を含んでいない場合、エンドにある(/*)を意味します。

--remotes[=<pattern>]

refs/remotesにおいてすべての参照がコマンドラインに<commit>としてリスト化されているかのように見せます。<pattern>が指定されている場合、リモート追跡ブランチを指定されたシェルグロブに一致するブランチに制限します。もしパターンが「 ? 」、「*」、「 [」を含んでいない場合、エンドにある(/*)を意味します。

--glob=<glob-pattern>

シェルグロブ<glob-pattern>に一致するすべての参照がコマンドラインに<commit>としてリスト化されているかのように見せます。先頭の「refs /」が欠落している場合、自動的に先頭に追加されます。もしパターンが「 ? 」、「*」、「 [」を含んでいない場合、エンドにある(/*)を意味します。

--exclude=<glob-pattern>

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

指定されたパターンがそれぞれ—branches--tags --remotesに適用される場合、refs/headsrefs/tagsrefs/remotes で始まるのではなく、--globもしくは –allが適用される場合、refs/で始める必要があります。末尾の「/ *」が意図されている場合、明示的に指定する必要があります。

--reflog

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

--alternate-refs

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

--single-worktree

デフォルトでは—all--reflog--indexed-objectsなどの複数のオプションがある場合、すべてのワークツリーが次のオプションによって検査されます(git-worktree[1]を参照)。このオプションは現在のワークツリーのみを検査するようにさせています。

--ignore-missing

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

--bisect

コマンドラインにおいて問題のあるバイセクト参照refs/bisect/badがリスト化され、その後に--notが続き、問題のないバイセクト参照refs/bisect/good-*が続くように見せます。

--stdin

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

--cherry-mark

--cherry-pick(以下を参照)と同様ですが、同等のコミットを省略ではなく= でマークし、同等でないコミットを+でマークします。

v--cherry-pick

コミットセットが対称差で制限されている場合、「反対側」の別のコミットと同じ変更を導入するコミットで省略します。

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

--left-only
--right-only

リストは対称差のそれぞれの側でのみコミットします。つまり、--left-rightによって<> とマークされるものだけです。

例えば、--cherry-pick --right-only A...BA にある、またはAのコミットとパッチと同等のBからのコミットを省略します。つまり、これはfrom 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

コミットの祖先のチェーンをたどる代わりに、参照ログエントリを最新のものから古いものに変更します。このオプションを使用する場合、除外するコミットを指定することはできません(つまり、「^ commit、commit1..commit2、およびcommit1 … commit2」の表記は使用できません)。

(明らかな理由で)onelinereference 以外の—prettyフォーマットを使用すると、出力に参照ログから取得された2ラインの追加情報が含まれます。出力の参照ログ指定子はいくつかのルールに応じて、ref@{Nth}Nthとは参照ログの逆時系列インデックス)またはref@{timestamp} (そのエントリのタイムスタンプ付き)として表示される場合があります。

  1. 開始点がref@{Nth}として指定されている場合、インデックスフォーマットを表示します。
  2. 開始点がref@{now}として指定されている場合、タイムスタンプフォーマットを表示します。
  3. どちらも使用されていないが、コマンドラインで–dateが指定されている場合、–dateで要求されたフォーマットでタイムスタンプを表示します。
  4. それ以外の場合、インデックスフォーマットを表示します。

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

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

--merge

マージが失敗した後、コンフリクトがあり、マージするすべてのヘッドに存在しないファイルに関連する参照を表示します。

--boundary

除外されたバウンダリーコミットを出力します。バウンダリーコミットには接頭辞-が付きます。

履歴の簡素化

特定の<path>を変更するコミットなど履歴の一部のみに関わる場合があります。ただし、履歴の簡略化には2つのポイントがあります。履歴を簡略化するための様々な戦略があり、1つはコミットの選択であり、もう1つはそれを行う方法です。

次のオプションは表示するコミットを選択します。

<paths>

指定された<paths>を変更するコミットが選択されます。

--simplify-by-decoration

いくつかのブランチまたはタグによって参照されるコミットが選択されます。

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

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

デフォルトモード

履歴をツリーの最終状態を説明する最もシンプルな履歴にします。最終結果が同じである場合(つまり、同じコンテンツのブランチをマージする場合)、いくつかのサイドブランチを削除するため、最もシンプルとなります。

--show-pulls

デフォルトモードからのすべてのコミットを含みますが、最初のペアレントへの「TREESAME」ではなく、後のペアレントへの「TREESAME」であるマージコミットも含めます。このモードはブランチに変更を「最初に導入した」マージコミットを表示するのに役立ちます。

--full-history

デフォルトモードと同じですが、一部の履歴を削除しません。

--dense

選択したコミットのみが表示され、意味のある履歴を持つコミットも表示されます。

--sparse

簡略化された履歴内のすべてのコミットが表示されます。

--simplify-merges

--full-historyへの追加オプションです。このマージに寄与する選択が行われたコミットがないため、結果の履歴から不要なマージを削除します。

--ancestry-path

表示するコミットの範囲(例えば、「commit1..commit2」または「commit2 ^ commit1」)が指定されている場合、「commit1」と「commit2」の間の祖先チェーンに直接存在するコミット、つまり、「commit1」の子孫と「commit2」の祖先の両方であるコミットのみを表示します。
より詳細な説明は次のとおりです。

<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」となります。
  • Cfooを変更しませんが、マージNはそれを「foobar」に変更するため、どのペアレントにとっても「TREESAME」ではありません。
  • Dfooを「baz」に設定します。そのマージOND の文字ラインを「foobarbaz」に結合します。つまり、どのペアレントにとっても「TREESAME」ではありません。
  • Equuxを「xyzzy」に変更し、そのマージ Pは文字列を「quuxxyzzy」に結合します。POに対して「TREESAME」ですが、Eに対してはそうではありません。
  • Xは、新しいファイル側を追加した独立したルートコミットであり、Yはそれを変更しました。YXへのTREESAMEです。そのマージQはPにサイドを追加し、QPへのTREESAMEですが、Yには追加されません。

rev-listfull-historyおよび/またはペアレントの書き換え(--parentsもしくは--childrenを介して)が使用されているかどうかに基づき、コミットを含めたり除外したりして、履歴をさかのぼります。以下の設定が可能です。

デフォルトモード

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

その結果、次のようになります。

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

「TREESAME」のペアレントにのみに従うルール(利用可能な場合)がBを考慮から完全に削除することに注意してください。CNを介して考慮されていましたが、「TREESAME」です。ルートコミットは空のツリーと比較されるので、Iは「!TREESAME」となります。

ペアレント/チャイルド関係は--parentsでのみ表示されますが、デフォルトモードで選択されたコミットには影響しないため、ペアレントラインを示しています。

--full-history without parent rewriting

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

I  A  B  N  D  O  P  Q

M はペアレントにとって「TREESAME」であるため除外されています。E、C、 B はすべてウォークされ、Bだけが「!TREESAME」となるので、他は表示されません。

ペアレントの書き換えがないと、コミット間のペアレント/チャイルド関係について話すことは実際には不可能であるため、コミットが切断されていることに注意してください。

--full-history with parent rewriting

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

マージは常に含まれています。ただし、ペアレントリストは書き換えられます。各ペアレントに沿って、自分自身に含まれていないコミットを削除します。これにより、以下となります。

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

上記を書き換えせずに--full-historyと比較してください。Eは「TREESAME」であるため削除されましたが、「P」のペアレントリストはEのペアレントIを含むように書き換えられます。CNXYQについても同じことが起こります。

上記の設定に加えて、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に対するNPQの主な違いに注意してください。

  • Nのペアレントリストは他のペアレントMの祖先であるため、削除します。それでもNは「!TREESAME」であるため、残ります。
  • Pのペアレントリストも同様に削除します。Pはペアレントが1つあり、「TREESAME」であるため、完全に削除されます。
  • QのペアレントリストではYXに簡略化されます。Xは「TREESAME」ルートであったため、削除されます。Qはペアレントが1つあり、「TREESAME」であるため、完全に削除されます。

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

--ancestry-path

表示されるコミットを指定されたコミット範囲内の「from」コミットと「to」コミットの間の祖先チェーンに直接あるコミットに制限します。つまり「to」コミットの祖先であるコミットと「from」コミットの子孫であるコミットのみを表示します。

ユースケースの例として、次のコミット履歴をご参考ください。

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

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

ただし、MのどのコミットがDによって導入されたバグでコンタミされており、修正が必要かを調べたい場合、実際にはD の子孫である「D..M」のサブセットのみを表示する必要があります。つまり、CKは除外となります。これはまさに--ancestry-pathオプションが行うということです。「D..M」範囲に適用すると、次のようになります。

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

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

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

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

この例においてはABX によって様々な方法で変更されたfile.txtを作成したとします。 シングルペアレントのコミットCZYfile.txtを変更しません。マージコミットMAB の両方の変更を含むようにマージのコンフリクトを解決することによって作成されるため、どちらにも「TREESAME」ではありません。ただし、マージコミットRMfile.txtの内容を無視し、Xfile.txtの内容のみを取得することによって作成されます。したがって、RXに対して「TREESAME」であり、Mではありません。最後に作成する自然なマージ解決NRfile.txtの内容を取得するため、NRに対して「TREESAME」ですが、Cではありません。マージコミットOP は最初のペアレントに対しては「TREESAME」ですが、2番目のペアレントであるZY に対してはそれぞれ「TREESAME」ではありません。
デフォルトモードを使用する場合、NRの両方に「TREESAME」ペアレントがあるため、これらのエッジはウォークされ、他のエッジは無視されます。結果の履歴グラフは次のとおりです。

I---X

--full-historyを使用するとGitはすべてのエッジをウォークします。これにより、コミットAB、およびマージMが検出されますが、マージコミットOPも表示されます。ペアレントを書き換えると、結果のグラフは次のようになります。

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

ここで、マージコミットOP は実際にはfile.txtに変更を加えなかったため、余分なノイズを引き起こします。古いバージョンのfile.txtに基づいたトピックのみをマージします。これは多くのコントリビューターが並行して作業し、トピックブランチを単一のトランクに沿ってマージするワークフローを使用するリポジトリにおける一般的な問題です。「manu」に無関係なマージが--full-historyの結果に表示されます。

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

    .-A---M--.
  / /    \
IBR
  \   / /
    \ / /
      `---X--'

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

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

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

--show-pulls

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

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

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

ここではコミットXR をそれぞれベースブランチにプルしたため、マージコミットRN が含まれています。これらのマージはコミットAB がデフォルトの履歴に表示されません。

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

    .-A---M--.   N
  / /    \ /
IBR
  \   / /
    \    / /
      `---X--'

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

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

Commit Ordering

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

--date-order

すべてのチャイルドが表示される前にペアレントを表示しませんが、それ以外の場合、コミットのタイムスタンプ順にコミットを表示します。

--author-date-order

すべてのチャイルドが表示される前にペアレントを表示しませんが、それ以外の場合、作成者のタイムスタンプ順にコミットを表示します。

--topo-order

すべてのチャイルドが表示される前にペアレントを表示せず、複数の履歴ラインが混在するコミットを表示しないようにします。

例えば、次のようなコミット履歴となります。

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

ここでの数字はコミットタイムスタンプの順序を示し、git rev-list--date-orderの仲間はタイムスタンプの順序でコミットを示します。8 7 6 5 4 3 21の順となります。

--topo-orderを使用すると8 6 5 3 7 4 2 1(もしくは8 7 4 2 6 5 3 1)と表示されます。2つのパラレルデベロップメントトラックからのコミットが混在して表示されないようにするために、いくつかの古いコミットが新しいコミットの前に表示されます。

--reverse

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

Object Traversal

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

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

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

--do-walk

以前の--no-walkを上書きします。

Commit Formatting

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

コミットログの内容を指定されたフォーマットで印刷します。<format>は「oneline、short、medium、full、fuller、reference、email、raw、format:<string>、tformat:<string>」のいずれかになります。 <format>が上記のいずれでもなく、「%placeholder」が含まれている場合、「-pretty = tformat:<format>」が指定されたかのように機能します。

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

注記:リポジトリ構成でデフォルトのプリティフォーマットを指定できます(git-config[1]を参照)。

--abbrev-commit

40バイトの16進コミットオブジェクト名全体を表示する代わりに、部分的なプレフィックスのみを表示します。デフォルト以外の桁数は「-abbrev = <n>」で指定できます(これは表示されている場合、差分出力も変更します)。

これにより80列の末端を使用している人にとって「–pretty = oneline」がずっと読みやすくなります。

--no-abbrev-commit

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

--oneline

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

--encoding=<encoding>

コミットオブジェクトはログメッセージに使用されるエンコーディングをエンコーディングヘッダーに記録します。このオプションを使用して、ユーザーが好むエンコーディングでコミットログメッセージを再コーディングするようにコマンドに指示できます。非配管コマンドの場合、これはデフォルトで「UTF-8」になります。オブジェクトがX でエンコードされていると示し、Xで出力している場合、オブジェクトを逐語的に出力することに注意してください。これはオリジナルのコミットの無効なシーケンスが出力にコピーされる可能性があることを意味します。

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

出力に表示する前にログメッセージでタブ展開を実行します(各タブを<n>の倍数である次の表示列に入力するのに十分なスペースで置き換えます)。--expand-tabs--expand-tabs=8の省略形であり、--no-expand-tabs--expand-tabs=0の省略形であり、タブの展開を無効にします。

デフォルトではタブはログメッセージを4スペースインデントにするきれいなフォーマットで展開します(つまりデフォルト、フル、およびフラーのミディアムです)。

--notes[=<ref>]

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

デフォルトでは表示されるメモはcore.notesRefおよびnotes.displayRef変数(または対応する環境上書き)にリスト化されているメモ参照からのものです。詳細についてはgit-config[1]を参照します。

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

複数の「–notes」オプションを組み合わせて、表示するノートをコントロールできます。 例えば、「-notes = foo」は「refs / notes / foo」からのメモのみを表示します。「–notes = foo –notes」は「refs / notes / foo」とデフォルトの「notesref(s)」の両方のメモを表示します。

--no-notes

メモを表示しません。これはノートが表示されるノート参照のリストをリセットすることにより、上記の--notesオプションを無効にします。オプションはコマンドラインで指定された順序で解析されます。例えば、「–notes–notes = foo –no-notes –notes = bar」は「refs / notes / bar」からのメモのみを表示します。

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

これらのオプションは非推奨となっています。その 代わりに上記の「–notes / -no-notes」オプションを使用してください。

--show-signature

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

--relative-date

--date=relativeと同義語です。

--date=<format>

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

--date=relativeは現在の時刻を基準にした日付を示します。例えば、「2時間前」などです。-localオプションは--date=relativeには影響しません。

--date=local--date=default-localのエイリアスとなっています。

--date=iso(または--date=iso8601)はタイムスタンプをISO8601のようなフォーマットで表示します。厳密なISO8601フォーマットとの違いは次のとおりです。

  • T 日付/時刻区切り文字の代わりにスペース
  • 時間とタイムゾーンの間のスペース
  • タイムゾーンの時間と分の間にコロンなし

--date=iso-strict(または--date=iso8601-strict)はタイムスタンプを厳密なISO8601フォーマットで表示します。

–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:...内部で処理される「%z」と「%Z」を除いて、フォーマット…をシステムstrftimeにフィードします。--date=format:%cを使用し、システムロケールの推奨フォーマットで日付を表示します。フォーマットプレースホルダーの完全なリストについては、strftimeのマニュアルを参照してください。-localを使用する場合、正しいシンタックスは--date=format-local:...です。

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

  • 曜日の後にコンマなし
  • ローカルタイムゾーンを使用する場合、タイムゾーンは省略

--parents

コミットのペアレントも印刷します(「commitparent…」のフォーム)。ペアレントの書き換えも可能にします。上記の履歴簡略化を参照してください。

--children

コミットのチャイルドも印刷します(「commitchild…」のフォーム)。ペアレントの書き換えも可能にします。上記の履歴簡略化を参照してください。

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

プリティフォーマット

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

いくつかの組み込みフォーマットがあり、以下で説明するように、<name>設定オプションを別のフォーマット名または「format」の「string」に設定することで、追加のフォーマットを定義できます(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:と同様にフォーマットプレースホルダーを使用し、その出力は--decorate--walk-reflogsなどの他のオプションの影響を受けません。

  • email
    From <hash> <date>
    From: <author>
    Date: <author date>
    Subject: [PATCH] <title line>
    
    <full commit message>
    
  • mboxrd
    メールと同様ですが、コミットメッセージの「From」で始まるライン(前に0個以上の「>」が付いている)は「>」で引用されているため、新しいコミットの開始と混同されることはありません。
  • raw
    「raw」フォーマットではコミットオブジェクトに格納されているとおりにコミット全体が表示されます。 特に「-abbrev」または「–no-abbrev」のどちらが使用されているかに関係なく、ハッシュは完全に表示され、ペアレント情報は移植や履歴の単純化を考慮せずに、真のペアレントコミットを示します。このフォーマットはコミットの表示方法に影響しますが、差分の表示方法には影響しないことに注意してください。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”」は次のようになります。

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

    プレースホルダーは次のとおりです。

    • シングルリテラル文字に展開されるプレースホルダー
      %n
      改行
      %%
      「raw」の%
      %x00
      16進コードから1バイトを出力
    • 後のプレースホルダーのフォーマットに影響するプレースホルダー
      %Cred
      色を赤に切り替え
      %Cgreen
      色を緑に切り替え
      %Cblue
      色を青に切り替え
      %Creset
      色をリセット
      %C(…)
      git-config[1]の「構成ファイル」セクションの値で説明されている色の指定です。デフォルトでは色はログ出力が有効になっている場合にのみ表示されます(color.diffcolor.ui、もしくは--colorによって、ターミナルに移動する場合は前者の自動設定を優先)。%C(auto,...)はデフォルトの履歴同義語として受け入れられます(例えば%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] or git-blame[1] を参照してください)
      %al
      作成者のメールローカルパート(@ サインの前のパート)
      %aL
      作成者のローカルパート(%alを参照) (mailmapについてはgit-shortlog[1] or git-blame[1]を参照してください)
      %ad
      作成日(フォーマット、日付オプション)
      %aD
      作成日RFC2822 スタイル
      %ar
      作成日, 関連
      %at
      作成日, UNIX テストスタンプ
      %ai
      作成日、ISO 8601のようなフォーマット
      %aI
      作成日、厳密なISO 8601フォーマット
      %as
      作成日、ショートフォーマット(YYYY-MM-DD)
      %cn
      コミッター名
      %cN
      コミッター名(mailmapについては git-shortlog[1] or git-blame[1] を参照してください)
      %ce
      コミッターのメール
      %cE
      コミッターのメール(mailmapについては git-shortlog[1] or git-blame[1] を参照してください)
      %cl
      コミッターのメールローカルパート(@ サインの前のパート)
      %cL
      コミッターのローカルパート(%clを参照、 mailmapについては git-shortlog[1] or git-blame[1] を参照してください)
      %cd
      コミッター日(フォーマット、日付オプション)
      %cD
      コミッター日、RFC2822スタイル
      %cr
      コミッター日、関連
      %ct
      コミッター日、UNIXタイムスタンプ
      %ci
      コミッター日、ISO 8601のようなフォーマット
      %cI
      コミッター日、厳密なISO 8601フォーマット
      %cs
      コミッター日、ショートフォーマット(YYYY-MM-DD)
      %d
      参照名、git-log[1]のオプションのデコレート
      %D
      参照名、「”(“, “)」のラッピングなし
      %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
      参照ログセレクター(例えば、refs/stash@{1}もしくは refs/stash@{2 minutes ago} フォーマットは-gオプションで説明されている規則に従います。@の前の部分はコマンドラインで指定された参照名です(したがって、git log -g refs/heads/masterrefs/heads/master@{0}を作成します)。
      %gd
      短縮参照ログセレクターです。%gDと同じですが、人が読みやすいように参照名部分が短縮されています(したがって、refs/heads/master は単なるmasterになります)。
      %gn
      参照ログID名
      %gN
      参照ログID名(mailmapについてはgit-shortlog[1]もしくは git-blame[1]を参照してください)
      %ge
      参照ログIDメール
      %gE
      参照ログIDメール(mailmapについてはgit-shortlog[1]もしくは git-blame[1]を参照してください)
      %gs
      参照ログ件名
      %(trailers[:options])
      git-interpret-trailers[1]によって解釈された本文のトレーラーを表示します。trailers文字列の後にはコロンと0個以上のコンマ区切りオプションを続けることができます。

      • key=<K>: 指定されたキーのトレーラーのみを表示します。マッチングは大文字と小文字を区別せずに行われ、末尾のコロンはオプションです。オプションが複数回指定されている場合、いずれかのキーに一致するトレーラーラインが表示されます。このオプションは自動的にonlyオプションを有効にして、トレーラーブロック内の非トレーラーラインを非表示にします。それが望ましくない場合はonly=falseで無効にすることができます。例えば%(trailers:key=Reviewed-by) はキーがReviewed-byのトレーラーを表示します。
      • only[=val]:トレーラーブロックからの非トレーラーラインを含めるかどうかを選択します。only キーワードの後には、オプションでtrueonyes のいずれかを省略したり、falseoffno のいずれかを付けてトレーラー以外のラインを表示したりできます。オプションが値なしで指定された場合、それが有効になります。複数回指定すると、最後の値が使用されます。
      • separator=<SEP>:トレーラーラインの間に挿入される区切り記号を指定します。このオプションが指定されていない場合、各トレーラーラインは改ライン文字で終了します。文字列SEPには上記のリテラルフォーマットコードが含まれる場合があります。区切り文字としてコンマを使用するには次のオプションとして解析するため、%x2C を使用する必要があります。セパレータオプションを複数回指定すると、最後のオプションのみが使用されます。例えば%(trailers:key=Ticket,separator=%x2C ) はキーが「チケット」であるすべてのトレーラーラインをカンマとスペースで区切って表示します。
      • unfold[=val]:まるでインタープレットトレーラーの--unfoldオプションが指定されたかのように機能します。onlyの場合と同じように、等号と明示的な値を続けることができます。例えば%(trailers:only,unfold=true)は展開され、すべてのトレーラーラインが表示されます。
      • valueonly[=val]:トレーラーラインの重要な部分をスキップして、値の部分のみを表示します。またこれはオプションで明示的な値を許可します。
        注記 一部のプレースホルダーはリビジョントラバーサルエンジンに指定された他のオプションに依存する場合があります。例えば%g* 参照ログオプションは参照ログエントリをトラバースしない限り(例えば、git log -gによって)、空の文字列を挿入します。%d および %Dプレースホルダーはコマンドラインで--decorateがまだ指定されていない場合、「ショート」とデコレーションフォーマットを使用します。
        プレースホルダーの%の後に+(プラス記号)を追加すると、プレースホルダーが空でない文字列に展開される場合に限り、展開の直前に改ラインが挿入されます。
        プレースホルダーの%の後に-(マイナス記号)を追加すると、プレースホルダーが空の文字列に展開された場合にのみ、展開の直前の連続するすべての改ラインが削除されます。
        プレースホルダーの%の後に「 “」(スペース)を追加すると、プレースホルダーが空でない文字列に展開される場合に限り、展開の直前にスペースが挿入されます。
    • tformat:
      「tformat」:フォーマットは「separator」セマンティクスの代わりに「terminator」セマンティクスを提供することを除き、フォーマットとまったく同じように機能します。つまり各コミットにはエントリ間に区切り文字を配置するのではなく、メッセージターミネータ文字(通常は改ライン)が追加されます。これは「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:があるかのように解釈されます。例えば、これら2つは同等となります。

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

差分フォーマット

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

-c--cc-m のいずれかが指定されていない限り、--patchなどの差分フォーマットが選択されていても、マージコミットで差分が表示されることはなく、-Sなどの検索オプションと一致しないことに注意してください。例外としては--first-parentが使用されている場合、マージは通常のシングルパアレンとコミットのように扱われます(これは「combined-diff」オプションを提供するか、--no-diff-mergesを使用して上書きできます)。

-c

このオプションを使用すると、マージコミットの差分出力はペアレントと結果のペアごとの差分を一度に1つずつ表示するのではなく、各パアレンとからの差分をマージ結果に同時に表示します。 さらに、すべてのペアレントから変更されたファイルのみが一覧表示されます。

--cc

このフラグは-c オプションを意味し、ペアレントのコンテンツに2つの変数しかない、関連のないハンクを省略してパッチ出力をさらに圧縮し、マージ結果は変更せずにそのうちの1つを選択します。

--combined-all-paths

このフラグにより結合された差分(マージコミットに使用)にすべてのペアレントからのファイルの名前が一覧表示されます。したがって、「-c」または「–cc」が指定されている場合にのみ効果があり、ファイル名の変更が検出された場合(つまり、名前変更またはコピーの検出が要求された場合)にのみ役立つ可能性があります。

-m

このフラグによりマージコミットは通常のコミットと同様に完全な差分を表示します。マージペアレントごとに個別のログエントリと差分が作成されます。例外としては--first-parentオプションが指定されている場合、最初のペアレントに対する差分のみが表示されることです。その場合、出力はマージがその時点で現在のブランチにもたらした変更を表します。

--diff-merges=off
--no-diff-merges

マージコミットの差分の出力を無効にします(デフォルト)。-m-c、または --ccを上書きするのに便利です。

-p
-u
--patch

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

-s
--no-patch

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

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

通常の3ラインではなく、<n>ラインのコンテキストで差分を作成します。--patchを意味します。-pを意味します。

--output=<file>

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

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

作成されたパッチの新しいライン、古いライン、またはコンテキストラインを示すために使用される文字を指定します。通常、それらはそれぞれ「+」、「-」、および「 ”」です。

--raw

コミットごとにロー差分フォーマットを使用して変更の概要を表示します。git-diff[1]の「ロー出力フォーマット」セクションを参照してください。これはログ自体をローフォーマットで表示することとは異なります。これは--format=rawで実現できます。

--patch-with-raw

-p–rawと同義語です。

-t

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

--indent-heuristic

差分ハンクのバウンダリーシフトするヒューリスティックを有効にして、パッチを読みやすくします。これがデフォルトとなります。

--no-indent-heuristic

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

--minimal

可能な限り最小の差分が作成されるように、時間を使ってください。

--patience

「patience diff」アルゴリズムを使用して差分を作成します。

--histogram

「histogram diff」アルゴリズムを使用して差分を作成します。

--anchored=<text>

「anchored diff」アルゴリズムを使用して差分を作成します。

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

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

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

差分アルゴリズムを選択します。変数は次のとおりです。
default, myers
基本的なグリーディー差分アルゴリズムです。 現在これがデフォルトとなっています。
minimal
可能な限り最小の差分が作成されるように、時間を使ってください。
patience
パッチを作成する時は「patience diff」アルゴリズムを使用してください。
histogram

このアルゴリズムは忍耐アルゴリズムを拡張し、「発生頻度の低い共通要素をサポート」します。

例えば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

ファイルの作成または削除(「 diffstat」において、「新規」または「終了」、オプションでシンボリックリンクの場合は「+ l」)およびモード変更(追加または削除の場合は「+ x」または「-x」)などの拡張ヘッダー情報の要約を出力します)。情報はファイル名部分とグラフ部分の間に置かれます。--statを意味します。

--numstat

--statに似ていますが、追加および削除されたライン数を10進表記で表示し、パス名を省略形なしで表示して、よりマシンフレンドリーにします。バイナリファイルの場合、0 0とする代わりに2つの-を出力します。

--shortstat

変更されたファイルの総数と追加および削除されたラインの数を含む--stat フォーマットの最後のラインのみを出力します。

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

各サブディレクトリの相対的な変更量の分布を出力します。--dirstatの動作はパラメーターのコンマ区切りリストをパスすることでカスタマイズできます。デフォルトはdiff.dirstat構成変数によってコントロールされます(git-config[1]を参照)。次のパラメータを使用できます。
changes
ソースから削除された、または宛先に追加されたラインをカウントして、「dirstat」番号を計算します。これはファイル内の純粋なコード移動の量を無視します。つまりファイル内のラインの再配置は他の変更ほどカウントされません。これはパラメーターが指定されていない場合のデフォルトとなります。
lines
通常のラインベースの差分分析を実行し、削除/追加されたライン数を合計し、「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

変更されたファイルの名前のみを表示します。

--name-status

変更されたファイルの名前とステータスのみを表示します。ステータス文字の意味については--diff-filterオプションの説明を参照してください。

--submodule[=<format>]

サブモジュールの違いをどのように表示するかを指定します。--submodule=short を指定すると、ショートフォーマットが使用されます。このフォーマットは範囲の最初と最後にコミットの名前を表示するだけです。--submoduleまたは--submodule=log を指定すると、ログフォーマットが使用されます。このフォーマットはgit-submodule[1] summaryのように範囲内のコミットをリスト化します。--submodule=diffを指定すると、差分フォーマットが使用されます。このフォーマットはコミット範囲間のサブモジュールの内容の変更のインライン差分を示します。構成オプションが設定されていない場合、デフォルトはdiff.submoduleまたはショートフォーマットです。

--color[=<when>]

--color差分を表示します。(つまり、「without =<when>」)は--color=alwaysと同じです。 <when>はalwaysneverautoのいずれかになります。

--no-color

色付き差分をオフにします–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

移動したテキストのブロックはブロックモードの場合と同様に検出されます。ブロックは「color.diff.{old,new}Moved」色、もしくは「color.diff.{old,new}MovedAlternative」のいずれかを使用してペイントされます。2つの色の間の変化は新しいブロックが検出されたことを示します。

dimmed-zebra

「zebra」に似ていますが、移動されたコードに関連のない部分の追加のディミングが実行されます。隣接する2つのブロックのバウンダリーラインは関連があると見なされ、残りは関連があるものではありません。dimmed_zebra は非推奨の同義語です。

--no-color-moved

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

--color-moved-ws=<modes>

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

no

移動検出を実行する時、空白を無視しません。

ignore-space-at-eol

EOLで空白の変更を無視します。

ignore-space-change

空白の量の変更は無視します。これはライン末端の空白を無視し、1つ以上の空白文字の他のすべてのシーケンスを同等と見なします。

ignore-all-space

ラインを比較するときは空白を無視します。これは、一方のラインに空白があり、もう一方のラインに空白がない場合でも違いを無視します。

allow-indentation-change

最初に移動検出で空白を無視し、空白の変更がラインごとに同じである場合にのみ、移動されたコードブロックをブロックにグループ化します。これは他のモードと互換性がありません。

--no-color-moved-ws

移動検出を実行する時、空白を無視しません、これは構成設定を上書きするために使用できます。--color-moved-ws=noと同じです。

--word-diff[=<mode>]

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

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

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

--check

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

--ws-error-highlight=<kind>

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

--full-index

パッチフォーマットの出力を作成する時、最初の文字の代わりに「インデックス」ラインにイメージ前およびイメージ後の完全なブロブオブジェクト名を表示します。

--binary

--full-indexに加えて、git-applyで適用できるバイナリ差分を出力します–patchを意味します。

--abbrev[=<n>]

40バイトの16進オブジェクト名全体を差分ローフォーマットの出力と差分ツリーヘッダーラインに表示する代わりに、部分的なプレフィックスのみを表示します。差分パッチ出フォーマットでは--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>]

差分を作成する場合、コミットごとに名前の変更を検出してレポートします。履歴をトラバースしながら名前を変更してファイルをフォローする方法については--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と併用する場合、削除/作成ペアの削除部分のプリイメージも省略してください。

-l<num>

–M-Cオプションには「O(n ^ 2)」処理時間が必要です。ここでnは潜在的な名前変更/コピーターゲットの数です。このオプションは名前変更/コピーターゲットの数が指定された数を超えた場合、名前変更/コピー検出が実行されないようにします。

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

オブジェクトはブロブまたはサブモジュールのコミットにすることができます。これは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>内のブロブパターンの順序によって決定されます。最初のパターンに一致するパス名を持つすべてのファイルが最初に出力され、2番目のパターンに一致する(ただし最初のパターンには一致しない)パス名を持つすべてのファイルが次に出力されます。パス名がどのパターンとも一致しないすべてのファイルはファイルの最後にすべて一致パターンがあるかのように出力されます。複数のパス名のランクが同じである場合(同じパターンに一致するが、以前のパターンには一致しない場合)、相互の出力順序は通常の順序となります。

<orderfile>は次のように解析されます。

  • 空白ラインは無視されるため、読みやすくするための区切り文字として使用できます。
  • ハッシュ( “#”)で始まるラインは無視されるため、コメントに使用できます。パターンがハッシュで始まる場合、パターンの先頭に円記号( “\”)を追加します。
  • 他の各ラインにはシングルパターンが含まれています。

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

-R

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

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

空白の変更は無視ます。これはライン末端の空白を無視し、1つ以上の空白文字の他のすべてのシーケンスを同等と見なします。

-w
--ignore-all-space

ラインを比較するときは空白を無視します。これは一方のラインに空白があり、もう一方のラインに空白がない場合でも、違いを無視します。

--ignore-blank-lines

ラインがすべて空白である変更は無視します。

--inter-hunk-context=<lines>

指定されたライン数までの差分ハンク間のコンテキストを表示し、それによって互いに近いハンクを融合します。デフォルトはdiff.interHunkContextで、「config」オプションが設定されていない場合は0となります。

-W
--function-context

変化の周囲の機能全体を表示します。

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

--src-prefix=<prefix>

「a /」の代わりに、指定されたソースプレフィックスを表示します。

--dst-prefix=<prefix>

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

--no-prefix

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

--line-prefix=<prefix>

出力のすべてのラインに追加のプレフィックスを付加します。

--ita-invisible-in-index

デフォルトでは「git add -N」によって追加されたエントリは「gitdiff」に既存の空のファイルとして表示され、「gitdiff–cached」に新しいファイルとして表示されます。このオプションを使用するとエントリは「git diff」では新しいファイルとして表示され、「gitdiff–cached」では存在しません。 このオプションは--ita-visible-in-indexで元に戻すことができます。どちらのオプションも実験的なものであり、将来削除される可能性があります。

これらの一般的なオプションの詳細についてはgitdiffcore[7]も参照してください。

「-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_DIFFGIT_DIFF_OPTS 環境変数を介してパッチテキストの作成をカスタマイズできます(git[1]を参照)。

「-p」オプションが作成するものは従来の差分フォーマットとは少し異なります。

    1. ますは次のような「gitdiff」ヘッダーがあります。
      diff --git a/file1 b/file2
      

      名前の変更/コピーが含まれない限り、a/と b/ のファイル名は同じです。特に作成または削除の場合でもa/ またはb/ファイル名の代わりに/dev/nullは使用されません。
      名前変更/コピーが含まれる場合、file1 とfile2 はそれぞれ名前変更/コピーのソースファイルの名前と名前変更/コピーが作成するファイルの名前を示します。

    2. その後、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/ プレフィックスは含まれません。
      類似性指数は変更されていないラインのパーセンテージであり、非類似性指数は変更されたラインのパーセンテージです。これは切り捨てられた整数であり、その後にパーセント記号が続きます。 したがって100%の類似性インデックス値は2つの等しいファイル用にリザーブされていますが、100%の非類似性は古いファイルから新しいファイルへのラインがないことを意味します。
      インデックスラインには変更前後のブロブオブジェクト名が含まれます。<mode>はファイルモードが変更されない場合に含まれます。それ以外の場合、別々のラインは古いモードと新しいモードを示します。

    3. 構成変数core.quotePathで説明されているように「unusual」文字を含むパス名が引用符で囲まれます(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
      

結合された差分形式

差分を作成するコマンドはマージを表示するときに-cまたは–cc オプションを使用して、結合された差分を作成できます。これはgit-diff[1]またはgit-show[1]とのマージを表示する時のデフォルトのフォーマットです。これらのコマンドのいずれかに-mオプションを指定して、マージの個々のペアレントとの差分の作成を強制できることにも注意してください。

「結合された差分」フォーマットは次のようになります。

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. まずは「gitdiff」ヘッダーがあり、次のようになります(-c オプションを使用した場合)。
        diff --combined file
        

        またはこのようになります(--ccオプションが使用されている場合)。

        diff --cc file
        
      2. その後、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>の差分で機能するように設計されており、組み合わせた差分形式では使用されません。

      3. その後、2ラインの「from-file / to-file」ヘッダーが続きます
        --- a/file
        +++ b/file
        

        従来の統合差分フォーマットの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
        

        この拡張フォーマットは名前変更またはコピー検出がアクティブな場合に役立ち、さまざまなペアレントでファイルのオリジナル名を確認できます。

      4. チャンクヘッダーのフォーマットが変更され、patch -p1に誤ってフィードされるのを防ぎます。結合された差分フォーマットはマージコミットの変更を確認するために作成されたものであり、適用するためのものではありません。この変更は拡張インデックスヘッダーの変更と似ています。
        @@@ <from-file-range> <from-file-range> <to-file-range> @@@
        

        結合された差分フォーマットのチャンクヘッダーには(ペアレントの数+ 1)@文字があります。

従来の統合差分フォーマットとは異なり、2つのファイルAとBが-(マイナスはAに表示されますが、Bでは削除されます)、+(プラスはAでは欠落していますが、Bに追加されます)、または" "( スペースは変更なし)プレフィックスを表示します。このフォーマットは2つ以上のファイル「file1、file2、…」を1つのファイルXと比較し、Xが各「fileN」とどのように異なるかを示します。ファイルNごとに1つの列が出力ラインの前に追加され、Xのラインが出力ラインとどのように異なるかを示します。

列Nの-文字はそのラインが「fileN」に表示されるが、結果には表示されないことを意味します。 列Nの+文字はそのラインが結果に表示され、「fileN」にそのラインがないことを意味します(つまり、そのペアレントの観点からラインが追加されたということです)。

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

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

git log --no-merges

コミット履歴全体を表示しますが、マージはスキップします

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

include/scsi またはdrivers/scsi サブディレクトリ内のファイルを変更したバージョンv2.6.12以降のすべてのコミットを表示します

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

過去2週間の変更をファイル「gitk」に表示します。–は「gitk」という名前の「branch」との混同を避けるために必要です

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

ローカルブランチのいずれかにあるが、オリジンのリモートトラッキングブランチのいずれにもないすべてのコミットを表示します(そのオリジンを持っているものにはありません)。
git log master --not --remotes=*/master

ローカルマスターにはあるが、リモートリポジトリマスターブランチにはないすべてのコミットを表示します。

git log -p -m --first-parent

変更の差分を含む履歴を表示しますが、「メインブランチ」の観点からのみ、マージされたブランチからのコミットをスキップし、マージによって導入された変更の完全な差分を表示します。これはシングル統合ブランチにとどまるときにすべてのトピックブランチをマージするという厳格なポリシーに従う場合にのみ意味があります。

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

main.cファイルのmain() 関数が時間の経過とともにどのように進化したかを示します。

git log -3

表示するコミットの数を3に制限します。

議論

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

      • ブロブオブジェクトの内容は解釈されていないバイトシーケンスとなっています。コアレベルでのエンコーディング変換はありません。
      • パス名はUTF-8正規化形式Cでエンコードされます。これはツリーオブジェクト、インデックスファイル、参照名、およびコマンドライン引数、環境変数、構成ファイルのパス名に適用されます(.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. 「gitcommit」および「gitcommit-tree」はプロジェクトでレガシーエンコーディングを使用していることを明示的に指定しない限り、与えられたコミットログメッセージが有効なUTF-8文字列のように見えない場合に警告を発行します。これを言う方法は次のように.git/configファイルに「i18n.commitencoding」を含めることです。
        [i18n]
        	commitEncoding = ISO-8859-1
        

        上記の設定で作成されたコミットオブジェクトは、encodingヘッダーにi18n.commitEncodingの値を記録します。これは後でそれらを見る他の人を助けるためです。このヘッダーがないということはコミットログメッセージがUTF-8でエンコードされていることを意味します。

      2. 「git log」、「git show」、「git blame」とその仲間たちはコミットオブジェクトのencodingヘッダーを調べ、特に指定がない限り、ログメッセージをUTF-8に再コーディングしようとします。 次のように.git/configファイルのi18n.logOutputEncodingを使用して目的の出力エンコーディングを指定できます。
        [i18n]
        	logOutputEncoding = ISO-8859-1
        

        この構成変数がない場合、代わりにi18n.commitEncodingの値が使用されます。

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

構成

コア変数についてはgit-config[1] を差分作成に関連する設定についてはgit-diff[1] を参照してください。

format.pretty

--formatオプションのデフォルトとなっています(上記の「Pretty Formats」を参照してください。)デフォルトはmediumです。

i18n.logOutputEncoding

ログを表示するときに使用するエンコーディングです(上記の説明を参照してください)。デフォルトで設定されている場合はi18n.commitEncodingの値になり、そうでない場合はUTF-8になります。

log.date

人が読めるフォーマット日付のデフォルトフォーマットです(--dateオプションと比較)。デフォルトは「default」となっています。これはSat May 8 19:35:34 2010 -0500のような日付を書き込むことを意味します。

フォーマットが「auto:foo」に設定されていて、ページャーが使用されている場合、フォーマット「foo」が日付フォーマットに使用されます。それ以外の場合は「デフォルト」が使用されます。

log.follow

trueの場合、git logは単一の<path>が指定されたときに--followオプションが使用されたかのように機能します。これには--followと同じ制限があります。つまり複数のファイルをフォローするために使用することはできず、非リニア履歴ではうまく機能しません。

log.showRoot

falseの場合、git logおよび関連するコマンドは最初のコミットを大きな作成イベントとして扱いませんgit log -p出力のルートコミットは差分を添付せずに表示されます。デフォルトはtrueです。

log.showSignature

trueの場合、git logおよび関連するコマンドは--show-signatureオプションがパスされたかのように機能します。

mailmap.*

git-shortlog[1]を参照してください。

notes.displayRef

core.notesRefまたはGIT_NOTES_REFによって設定されたデフォルトに加えて、コマンドのlogファミリでコミットメッセージを表示するときにメモを読み取るための参照です。git-notes[1]を参照してください。

省略されていない参照名またはグロブである可能性があり、複数回指定される可能性があります。 存在しない参照に対して警告が発行されますが、どの参照とも一致しないグロ部は無視されます。

この設定は--no-notesオプションで無効にしたり、GIT_NOTES_DISPLAY_REF環境変数で上書きしたり、--notes=<ref>オプションで上書きしたりできます。

GIT

git[1]パッケージソフトの一部

git公式ドキュメント

log