日本語 ▾ トピック ▾ 最新バージョン ▾ git-shortlog は 2.49.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>：git log の --format オプションが受け入れる任意の文字列です。（git-log[1] の「PRETTY FORMATS」セクションを参照してください。）

    トレーラーを含まないコミットはカウントされないことに注意してください。同様に、複数のトレーラー（例: 複数の署名）を持つコミットは複数回カウントされる場合があります（ただし、そのコミット内のユニークなトレーラー値ごとに1回のみ）。

    Shortlog は、各トレーラー値を name <email> の識別子として解析しようとします。成功した場合、メールマップが適用され、--email オプションが指定されていない限り、メールアドレスは省略されます。値が識別子として解析できない場合、その値は文字通り完全に解釈されます。

--group が複数回指定された場合、コミットは各値でカウントされます（ただし、これもそのコミット内のユニークな値ごとに1回のみです）。たとえば、git shortlog --group=author --group=trailer:co-authored-by は著者と共著者（co-authors）の両方をカウントします。

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

指定されたパターン（正規表現）に一致するリフログエントリを持つコミットに出力を制限します。複数の --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 がそれらをサポートするようにコンパイルされていない場合、このオプションを指定すると終了します。

--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/ 内のすべての参照と 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/heads、refs/tags、または refs/remotes で始まってはならず、--glob または --all に適用される場合は refs/ で始まらなければなりません。末尾に /* を意図する場合、明示的に指定する必要があります。

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

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

--reflog

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

--alternate-refs

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

--single-worktree

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

--ignore-missing

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

--bisect

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

--stdin

コマンドラインから引数を受け取るだけでなく、標準入力からも読み取ります。これは、コミットや --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 は、B のコミットのうち、A に存在するコミット、または A のコミットとパッチ的に同等なものを省略します。言い換えれば、これは 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

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

oneline および reference 以外の --pretty フォーマットを使用すると（明白な理由により）、出力にリフログから取得された2行の追加情報が含まれます。出力中のリフログ指定子は、いくつかのルールに応じて ref@{<Nth>}（ここで <Nth> はリフログの逆時系列インデックス）または 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-way マージからの競合を解決する際に関連するコミットを表示するために使用できます。

--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> の子孫、または <commit> 自身であるコミットのみを表示します。コミットが指定されていない場合、commit1（範囲の除外部分）を <commit> として使用します。複数回渡すことができ、その場合、指定されたコミットのいずれかであるか、それらのいずれかの祖先または子孫である場合にコミットが含まれます。

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

foo を <paths> として指定したと仮定します。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 は foo を「foobar」に変更するため、どの親に対しても TREESAME ではありません。

  • D は foo を「baz」に設定します。そのマージ O は N と D からの文字列を結合して「foobarbaz」にします。つまり、どの親に対しても TREESAME ではありません。

  • E は quux を「xyzzy」に変更し、そのマージ P は文字列を結合して「quux xyzzy」にします。P は O に対して TREESAME ですが、E に対してはそうではありません。

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

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点異なります: マージが親のいずれかに対して 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 がない場合でも、これはマージを簡略化します。つまり、親のいずれかが 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 が削除されました。なぜなら、I がもう一方の親 M の祖先であるためです。それでも N は !TREESAME であるため残りました。

  • 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..M のうち実際に D の子孫である部分のみ、つまり 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 は R に対して TREESAME ですが、C に対してはそうではありません。マージコミット 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番目の問題は監査に関するものです。多くの貢献者が同じリポジトリで作業している場合、どのマージコミットが重要なブランチに変更を導入したかが重要です。上記の問題のあるマージ 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