日本語 ▾ トピック ▾ 最新バージョン ▾ git-shortlog は 2.50.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] の "Commit Formatting" セクションにある --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 です。

幅が 0 の場合、行を折り返さずにインデントします。

<revision-range>

指定されたリビジョン範囲内のコミットのみを表示します。HEAD （つまり、現在のコミットに至る全履歴）です。origin..HEAD は、現在のコミット（つまり HEAD）から到達可能なすべてのコミットのうち、origin からは到達できないコミットを指定します。gitrevisions[7] の "Specifying Ranges" セクションを参照してください。

[--] <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 が有効な場合、注釈からのメッセージはログメッセージの一部であるかのように一致します。

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

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

--reflog

reflogs で言及されているすべてのオブジェクトが、コマンドラインで <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 は、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 エントリから古いものへと reflog エントリをたどります。このオプションを使用する場合、除外するコミットを指定することはできません（つまり、^commit、commit1..commit2、および commit1...commit2 の表記は使用できません）。

oneline と reference 以外の --pretty フォーマット（明らかな理由で）を使用すると、出力に 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> の子孫、または <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 は P に side を追加し、Q は P には TREESAME ですが、Y には TREESAME ではありません。

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

デフォルトモード

コミットは、いずれかの親に TREESAME でない場合に含められます（ただし、これは変更可能です。下記の --sparse を参照）。コミットがマージであり、いずれかの親に 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 が削除されました。なぜなら、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 自体も）を除くすべてのコミットになります。

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

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

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

代わりに、この範囲内の特定のトピックと、そのトピックの影響を受けるすべてのコミットに興味がある場合、そのトピックを祖先パスに含む D..M のサブセットのみを表示したいかもしれません。したがって、たとえば --ancestry-path=H D..M を使用すると、次の結果になります。

		E
		 \
	      C---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