Git
英語 ▾ トピック ▾ 最新バージョン ▾ git-shortlog は 2.45.0 で最後に更新されました

名前

git-shortlog - git log 出力を要約する

概要

git shortlog [<options>] [<revision-range>] [[--] <path>…​]
git log --pretty=short | git shortlog [<options>]

説明

リリースアナウンスに含めるのに適した形式で、git log 出力を要約します。各コミットは、作成者とタイトルごとにグループ化されます。

さらに、「[PATCH]」はコミットの説明から削除されます。

コマンドラインでリビジョンが渡されず、標準入力がターミナルではなく、現在のブランチがない場合、git shortlog は現在のリポジトリを参照せずに、標準入力から読み取ったログのサマリーを出力します。

オプション

-n
--numbered

作成者のアルファベット順ではなく、作成者ごとのコミット数に従って出力をソートします。

-s
--summary

コミットの説明を抑制し、コミット数の概要のみを提供します。

-e
--email

各作成者のメールアドレスを表示します。

--format[=<format>]

コミットの件名ではなく、他の情報を使用して各コミットを記述します。<format> は、git log の--formatオプションで受け入れられる任意の文字列です（例：* [%h] %s）。（git-log[1]の「PRETTY FORMATS」セクションを参照してください。）

Each pretty-printed commit will be rewrapped before it is shown.
--date=<format>

指定された日付文字列に従ってフォーマットされた日付を表示します。（git-log[1]の「コミットのフォーマット」セクションの--dateオプションを参照してください）。--group=format:<format>と併用すると便利です。

--group=<type>

<type>に基づいてコミットをグループ化します。--groupオプションを指定しない場合、デフォルトはauthorです。<type>は次のいずれかです。

  • author、コミットは作成者ごとにグループ化されます

  • committer、コミットはコミッターごとにグループ化されます（-cと同じです）

  • trailer:<field>、<field>は大文字と小文字を区別しないコミットメッセージのトレーラーとして解釈されます（git-interpret-trailers[1]を参照）。たとえば、プロジェクトでReviewed-byトレーラーを使用している場合、git shortlog -ns --group=trailer:reviewed-byを使用して、誰がレビューを行ったかを確認できます。

  • format:<format>、--formatオプションで受け入れられる任意の文字列です。（git-log[1]の「PRETTY FORMATS」セクションを参照してください。）

    トレーラーが含まれていないコミットはカウントされません。同様に、複数のトレーラー（例：複数の署名）を持つコミットは複数回カウントされる場合があります（ただし、そのコミット内の固有のトレーラー値ごとに1回のみです）。

    Shortlogは、各トレーラー値をname <email>アイデンティティとして解析しようとします。成功すると、mailmapが適用され、--emailオプションが指定されていない限り、メールは省略されます。値をアイデンティティとして解析できない場合、文字通り完全に取得されます。

--groupを複数回指定すると、各値の下でコミットがカウントされます（ただし、そのコミット内の固有の値ごとに1回のみです）。たとえば、git shortlog --group=author --group=trailer:co-authored-byは、作成者と共同作成者の両方をカウントします。

-c
--committer

これは--group=committerのエイリアスです。

-w[<width>[,<indent1>[,<indent2>]]]

各行をwidthで折り返して出力を折り返します。各エントリの最初の行はindent1スペースでインデントされ、2行目以降の行はindent2スペースでインデントされます。width、indent1、indent2のデフォルトはそれぞれ76、6、9です。

widthが0（ゼロ）の場合、行を折り返さずに出力行をインデントします。

<revision-range>

指定されたリビジョン範囲内のコミットのみを表示します。<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>

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

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

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

--since-as-filter=<date>

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

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

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

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

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

--grep-reflog=<pattern>

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

--grep=<pattern>

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

--notesが有効な場合、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がそれらのサポートを有効にしてコンパイルされていない場合、このオプションを指定するとエラーが発生します。

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

含めるコミットを見つける際に、マージコミットが表示されたら、最初の親コミットのみを辿ります。このオプションは、特定のトピックブランチの進化を表示する際に、より良い概要を提供できます。なぜなら、トピックブランチへのマージは、時々更新されたアップストリームに合わせるためだけのことが多いからです。このオプションを使用すると、そのようなマージによって履歴に持ち込まれた個々のコミットを無視できます。

--exclude-first-parent-only

除外するコミットを見つける場合（^を使用）、マージコミットが表示されたら、最初の親コミットのみを辿ります。これは、任意のマージが有効なトピックブランチの変更であることを考えると、リモートブランチから分岐した時点からのトピックブランチの変更セットを見つけるために使用できます。

--not

次の--notまで、すべての後続のレビジョン指定子の^プレフィックス（またはその不足）の意味を反転します。コマンドラインで--stdinの前に使用した場合、stdinを介して渡されるリビジョンは影響を受けません。逆に、標準入力から渡された場合、コマンドラインで渡されたリビジョンは影響を受けません。

--all

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

--branches[=<pattern>]

refs/heads内のすべてのrefsが、コマンドラインに<commit>としてリストされているかのように振る舞います。<pattern>が指定されている場合、指定されたシェルglobに一致するブランチに制限します。パターンに?、*、または[がない場合、末尾に/*が暗黙的に追加されます。

--tags[=<pattern>]

refs/tags内のすべてのrefsが、コマンドラインに<commit>としてリストされているかのように振る舞います。<pattern>が指定されている場合、指定されたシェルglobに一致するタグに制限します。パターンに?、*、または[がない場合、末尾に/*が暗黙的に追加されます。

--remotes[=<pattern>]

refs/remotes内のすべてのrefsが、コマンドラインに<commit>としてリストされているかのように振る舞います。<pattern>が指定されている場合、指定されたシェルglobに一致するリモート追跡ブランチに制限します。パターンに?、*、または[がない場合、末尾に/*が暗黙的に追加されます。

--glob=<glob-pattern>

シェルglob <glob-pattern>に一致するすべてのrefsが、コマンドラインに<commit>としてリストされているかのように振る舞います。先頭のrefs/は、存在しない場合は自動的に追加されます。パターンに?、*、または[がない場合、末尾に/*が暗黙的に追加されます。

--exclude=<glob-pattern>

次の--all、--branches、--tags、--remotes、または--globが考慮する可能性のある、<glob-pattern>に一致するrefsを含めません。このオプションの繰り返しは、次の--all、--branches、--tags、--remotes、または--globオプションまで除外パターンを蓄積します（他のオプションまたは引数は蓄積されたパターンをクリアしません）。

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

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

適切なfetch.hideRefs、receive.hideRefs、またはuploadpack.hideRefs設定とtransfer.hideRefsを参照して、git-fetch、git-receive-pack、またはgit-upload-packによって非表示になるrefsを含めません（git-config[1]を参照）。このオプションは次の擬似refオプション--allまたは--globに影響し、それらの処理後にクリアされます。

--reflog

reflogによって言及されているすべてのオブジェクトが、コマンドラインに<commit>としてリストされているかのように振る舞います。

--alternate-refs

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

--single-worktree

デフォルトでは、複数のワーキングツリーが存在する場合、次のオプションによってすべてのワーキングツリーが検査されます（git-worktree[1]を参照）：--all、--reflog、および--indexed-objects。このオプションは、それらが現在のワーキングツリーのみを検査するように強制します。

--ignore-missing

入力に無効なオブジェクト名が表示された場合、その不正な入力が与えられていないかのように振る舞います。

--bisect

不正なバイセクションref refs/bisect/badがリストされており、コマンドラインで--notと良好なバイセクションref refs/bisect/good-*が続くかのように振る舞います。

--stdin

コマンドラインから引数を受け取ることに加えて、標準入力からも読み取ります。これは、--allや--glob=などのコミットと擬似オプションを受け入れます。--セパレータが表示されると、後続の入力はパスとして扱われ、結果を制限するために使用されます。標準入力から読み取られる--notのようなフラグは、同じ方法で渡される引数に対してのみ尊重され、後続のコマンドライン引数には影響しません。

--cherry-mark

--cherry-pick（下記参照）に似ていますが、同等のコミットを=でマークし、同等でないコミットを+でマークします。

--cherry-pick

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

たとえば、ブランチAとBの2つがある場合、それらの片側にあるコミットをリストする一般的な方法は--left-rightを使用することです（--left-rightオプションの説明にある例を参照）。ただし、これは、もう一方のブランチからチェリーピックされたコミットを表示します（たとえば、「b上の3番目」はブランチAからチェリーピックされている可能性があります）。このオプションを使用すると、そのようなコミットのペアは出力から除外されます。

--left-only
--right-only

対称差のそれぞれの側にあるコミットのみをリストします。つまり、--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 log --cherry upstream...mybranchを使用してマークするのに役立ちます。これはgit cherry upstream mybranchに似ています。

-g
--walk-reflogs

コミットの祖先チェーンを辿る代わりに、最新のreflogエントリから古いものへと辿ります。このオプションを使用する場合、除外するコミットを指定できません（つまり、^commit、commit1..commit2、およびcommit1...commit2表記は使用できません）。

--pretty オプションで、oneline および reference 以外のフォーマットを指定した場合（理由は明らかです）、reflog から取得した2行の追加情報が出力に含まれます。出力される reflog 記述子は、ref@{<Nth>}（ここで<Nth> は reflog 内の逆時間順インデックス）または ref@{<timestamp>}（ここで<timestamp> はそのエントリのタイムスタンプ）として表示されます。これはいくつかのルールに基づいて決定されます。

  1. 開始点が ref@{<Nth>} として指定されている場合、インデックス形式が表示されます。

  2. 開始点が ref@{now} として指定されている場合、タイムスタンプ形式が表示されます。

  3. どちらも使用されていませんが、コマンドラインで --date オプションが指定されている場合、--date で要求されたフォーマットのタイムスタンプが表示されます。

  4. それ以外の場合は、インデックス形式が表示されます。

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

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

--merge

HEAD...<other> の範囲内で、競合パスに影響を与えるコミットを表示します。ここで <other> は MERGE_HEAD、CHERRY_PICK_HEAD、REVERT_HEAD、または REBASE_HEAD 内の最初に存在する擬似参照です。インデックスにマージされていないエントリがある場合にのみ機能します。このオプションは、3方マージからの競合を解決する際に関連するコミットを表示するために使用できます。

--boundary

除外された境界コミットを出力します。境界コミットには - が接頭辞として付加されます。

履歴の簡素化

特定の <path> を変更するコミットなど、履歴の一部のみに関心がある場合があります。しかし、履歴の簡素化には2つの部分があります。1つはコミットの選択、もう1つは方法です。履歴を簡素化する方法は様々です。

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

<paths>

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

--simplify-by-decoration

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

意味のある履歴を得るために、追加のコミットが表示される場合があります。

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

デフォルトモード

ツリーの最終状態を説明する最も単純な履歴に履歴を簡素化します。最終結果が同じ（つまり、同じコンテンツを持つブランチのマージ）場合、いくつかの枝分かれを削除するため、最も単純です。

--show-pulls

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

--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に対してフィルタリングされたdiffでは、それぞれ異なるものと等しいものに見えます。）

以下では、簡素化設定の違いを示すために、常に同じ例履歴を参照します。このコミットグラフでは、ファイル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は文字列を「quux xyzzy」に結合します。PはOとTREESAMEですが、EとはTREESAMEではありません。

  • Xは新しいファイルsideを追加した独立したルートコミットであり、Yはそれを変更しました。YはXとTREESAMEです。そのマージQはsideをPに追加し、QはPとTREESAMEですが、YとはTREESAMEではありません。

rev-listは履歴を逆順にたどり、--full-historyおよび/または親の書き換え（--parentsまたは--children経由）の使用に基づいてコミットを含めたり除外したりします。次の設定が利用可能です。

デフォルトモード

コミットは、親のいずれともTREESAMEでない場合に含まれます（ただし、これは変更できます。後述の--sparseを参照）。コミットがマージであり、1つの親とTREESAMEだった場合、その親のみを辿ります。（TREESAMEな親が複数ある場合でも、そのうちの1つだけを辿ります。）それ以外の場合は、すべての親を辿ります。

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

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

TREESAMEな親がある場合、その親だけを辿るというルールにより、Bが完全に考慮から除外されていることに注意してください。CはN経由で考慮されましたが、TREESAMEです。ルートコミットは空のツリーと比較されるため、Iは!TREESAMEです。

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

親の書き換えなしの--full-history

このモードは、1点でデフォルトと異なります。マージのすべての親を常に辿ります。たとえそれが親の1つとTREESAMEであってもです。マージの複数の側に含まれるコミットがある場合でも、マージ自体が含まれるとは限りません。この例では、次のようになります。

	I  A  B  N  D  O  P  Q

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

親の書き換えがない場合、コミット間の親/子の関係について話すことは実際には不可能であるため、それらを切り離して表示します。

親の書き換えによる--full-history

通常のコミットは、!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の場合、その親のみを辿るため、マージの他の側は決して辿られません。

--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の親リストからIが削除されました。これは他の親Mの祖先だからです。それでも、Nは!TREESAMEであるため残りました。

  • Pの親リストからも同様にIが削除されました。Pはその後、1つの親を持ち、TREESAMEであるため完全に削除されました。

  • Qの親リストでは、YがXに簡素化されました。Xはその後、TREESAMEなルートであったため削除されました。Qはその後、1つの親を持ち、TREESAMEであるため完全に削除されました。

もう1つの簡素化モードがあります。

--ancestry-path[=<commit>]

表示するコミットを、<commit>の祖先であるコミット、<commit>の子孫であるコミット、または<commit>自体のコミットに限定します。

使用例として、次のコミット履歴を考えてみましょう。

	    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の部分集合のみを表示したい場合があります。つまり、CとKを除外します。これはまさに--ancestry-pathオプションが行うことです。D..M範囲に適用すると、次のようになります。

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

D..M範囲に適用した場合、同じ意味ですが、より明確な--ancestry-path=Dを使用することもできます。

代わりに、この範囲内の特定のトピックとそのトピックに影響を受けるすべてのコミットに関心がある場合、そのトピックがその祖先パスに含まれている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にはTREESAMEではありません。最後に、Nを作成するための自然なマージ解決は、Rにおけるfile.txtの内容を採用することであるため、NはRにはTREESAMEですが、CにはTREESAMEではありません。マージコミットOとPは、それぞれ最初の親にはTREESAMEですが、2番目の親であるZとYにはTREESAMEではありません。

デフォルトモードを使用する場合、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番目の問題は監査の問題です。多くの貢献者が同じリポジトリで作業している場合、どのマージコミットが重要なブランチに変更を導入したかが重要になります。上記の厄介なマージRは、重要なブランチにマージするために使用されたマージコミットではない可能性が高いです。代わりに、マージNはRとXを重要なブランチにマージするために使用されました。このコミットには、変更XがコミットメッセージにおいてAとBからの変更を上書きした理由に関する情報が含まれている可能性があります。

--show-pulls

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

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

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

ここでは、マージコミットRとNは、それぞれコミットXとRをベースブランチにプルしたため含まれています。これらのマージは、コミット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としてマークされます（簡略化される可能性があります）。

作成者のマッピング

gitmailmap[5]を参照してください。

git shortlogがリポジトリの外で実行される場合（標準入力でログの内容を処理する場合）、現在のディレクトリにある.mailmapファイルを探します。

Git

git[1]スイートの一部

scroll-to-top