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

名称

git-replay - 実験的:新しいベースでコミットを再生します。ベアリポジトリでも動作します。

概要

(EXPERIMENTAL!) git replay ([--contained] --onto <newbase> | --advance <branch>) <revision-range>…​

説明

コミットの範囲を取得し、新しい場所に再生します。作業ツリーとインデックスは変更せず、参照も更新しません。このコマンドの出力は、git update-ref --stdinへの入力として使用することを目的としています。これにより、関連するブランチが更新されます(以下の出力セクションを参照)。

このコマンドは実験的です。動作が変更される可能性があります。

オプション

--onto <newbase>

新しいコミットを作成する開始点。既存のブランチ名だけでなく、有効なコミットであれば何でもかまいません。

--ontoが指定されている場合、出力内のupdate-refコマンドは、リビジョン範囲内のブランチを新しいコミットを指すように更新します。これは、git rebase --update-refsが影響を受ける範囲内の複数のブランチを更新する方法と同様です。

--advance <branch>

新しいコミットを作成する開始点。ブランチ名である必要があります。

--advanceが指定されている場合、出力内のupdate-refコマンドは、--advanceに引数として渡されたブランチを新しいコミットを指すように更新します(つまり、これはcherry-pick操作を模倣します)。

<revision-range>

再生するコミットの範囲。複数の<revision-range>を渡すことができますが、--advance <branch>モードでは、単一の先端を持つ必要があります。これにより、<branch>がどこを指すべきかが明確になります。git-rev-parse[1]の「範囲の指定」と、以下の「コミットの制限」オプションを参照してください。

コミットの制限

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

一般的に、より多くのオプションを使用すると、出力はさらに制限されます(例:--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がそれらのサポートを有効にしてコンパイルされていない場合、このオプションを提供すると、Gitは終了します。

--remove-empty

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

--merges

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

--no-merges

2つ以上の親を持つコミットを出力しません。これは--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/headsrefs/tagsrefs/remotes で始まるべきではなく、--glob または --all に適用される場合は refs/ で始まる必要があります。末尾の /* を意図している場合は、明示的に指定する必要があります。

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

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

--reflog

reflog によって参照されるすべてのオブジェクトが、コマンドラインに <commit> として一覧表示されているかのように振る舞います。

--alternate-refs

代替リポジトリの ref の先端として言及されているすべてのオブジェクトがコマンドラインに一覧表示されているかのように振る舞います。代替リポジトリとは、そのオブジェクトディレクトリが 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

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

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

--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 エントリを辿ります。このオプションを使用する場合は、除外するコミットを指定できません(つまり、^commitcommit1..commit2、および commit1...commit2 表記を使用できません)。

--pretty 形式が onelinereference 以外の場合(明らかな理由から)、出力には 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

MERGE_HEADCHERRY_PICK_HEADREVERT_HEAD、または REBASE_HEAD の最初の既存の擬似 ref である <other> の範囲 HEAD...<other> で、競合パスに影響を与えるコミットを表示します。インデックスにマージされていないエントリがある場合にのみ機能します。このオプションは、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*)が指定された場合、その範囲内のコミットのうち、`` の祖先であるもの、`` の子孫であるもの、または `` 自体のみを表示します。コミットが指定されていない場合は、範囲から除外された部分( *commit1* )を `` として使用します。複数回渡すことができます。その場合、指定されたコミットのいずれか、またはそれらのコミットの祖先または子孫である場合にコミットが含まれます。

より詳細な説明を以下に示します。

`` として `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` を参照)。コミットがマージであり、1つの親に対して TREESAME であった場合、その親のみをたどります。(TREESAME な親が複数ある場合でも、そのうちの1つだけをたどります。)それ以外の場合は、すべての親をたどります。

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

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

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

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

親の書き換えを行わない `--full-history`

このモードは、デフォルトモードとは1点異なります。マージのすべての親を常にたどり、1つの親に対して TREESAME である場合でも同様です。マージの複数の側に含まれるコミットがある場合でも、マージ自体が !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 であるため完全に削除されました。

別の簡略化モードがあります。

--ancestry-path[=<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

`--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` に対しては 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--'

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

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

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

--show-pulls

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

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

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

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

--show-pulls--simplify-mergesを組み合わせると、グラフに必要なすべての情報が含まれます。

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

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

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

コミット順序

デフォルトでは、コミットは逆時系列で表示されます。

--date-order

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

--author-date-order

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

--topo-order

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

たとえば、このようなコミット履歴では

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

数字はコミットタイムスタンプの順序を示しており、--date-orderを使用するgit rev-listなどは、タイムスタンプの順序でコミットを表示します:8 7 6 5 4 3 2 1。

--topo-orderを使用すると、8 6 5 3 7 4 2 1(または8 7 4 2 6 5 3 1)と表示されます。2つの並列開発トラックからのコミットが混在して表示されるのを避けるために、古いコミットが新しいコミットよりも先に表示されます。

--reverse

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

オブジェクトトラバーサル

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

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

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

--do-walk

前の--no-walkをオーバーライドします。

コミットのフォーマット

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

指定されたフォーマットでコミットログの内容を整形して出力します。ここで、<format>は、onelineshortmediumfullfullerreferenceemailrawformat:<string>、およびtformat:<string>のいずれかになります。<format>が上記のいずれでもなく、%placeholderが含まれている場合、--pretty=tformat:<format>が指定された場合と同様に動作します。

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

注:リポジトリ設定でデフォルトの整形フォーマットを指定できます(git-config[1]を参照)。

--abbrev-commit

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

これにより、「--pretty=oneline」は、80桁の端末を使用しているユーザーにとってはるかに読みやすくなります。

--no-abbrev-commit

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

--oneline

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

--encoding=<encoding>

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

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

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

デフォルトでは、ログメッセージを4スペースでインデントする整形フォーマット(つまり、デフォルトのmediumfull、およびfuller)でタブが展開されます。

--notes[=<ref>]

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

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

オプションの<ref>引数を使用すると、表示するノートを見つけるための参照を使用します。参照は、refs/notes/で始まる場合に完全な参照名を指定できます。notes/で始まる場合、refs/がプレフィックスとして追加され、それ以外の場合はrefs/notes/がプレフィックスとして追加されて、参照の完全名が形成されます。

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

--no-notes

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

--show-notes-by-default

特定のノートを表示するためのオプションが指定されていない限り、デフォルトのノートを表示します。

--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)は、ISO 8601に似た形式でタイムスタンプを表示します。厳密なISO 8601形式との違いは次のとおりです。

  • 日付/時刻デリミターとしてTの代わりにスペースを使用する

  • 時刻とタイムゾーンの間にスペースを入れる

  • タイムゾーンの時と分の間にコロンを入れない

--date=iso-strict(または--date=iso8601-strict)は、厳密なISO 8601形式でタイムスタンプを表示します。

--date=rfc(または--date=rfc2822)は、電子メールメッセージによくあるRFC 2822形式でタイムスタンプを表示します。

--date=shortは、時刻ではなく日付のみをYYYY-MM-DD形式で表示します。

--date=rawは、エポック(1970-01-01 00:00:00 UTC)からの秒数を表示し、その後にスペースを空けて、UTCからのオフセットとしてのタイムゾーンを表示します(+または-と4桁の数字。最初の2桁は時間、後の2桁は分)。つまり、タイムスタンプがstrftime("%s %z")でフォーマットされた場合と同様です。-localオプションは、エポックからの秒数(常にUTCで測定されます)には影響しませんが、付随するタイムゾーン値を切り替えます。

--date=humanは、タイムゾーンが現在のタイムゾーンと一致しない場合にタイムゾーンを表示し、一致する場合には日付全体を出力しません(つまり、「今年」の日付の場合は年を出力せず、過去数日の場合は曜日だけを表示します)。古い日付の場合は、時と分も省略されます。

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

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

--date=default はデフォルトのフォーマットで、ctime(3) の出力に基づいています。曜日を3文字、月を3文字、日、時分秒を"HH:MM:SS"形式で、それに4桁の年とタイムゾーン情報を表示します。ただし、ローカルタイムゾーンを使用する場合は、タイムゾーン情報は表示されません。例:Thu Jan 1 00:00:00 1970 +0000

--parents

コミットの親も表示します("commit parent…" の形式)。また、親の書き換えも有効になります。上記の「履歴の簡素化」を参照してください。

--children

コミットの子も表示します("commit child…" の形式)。また、親の書き換えも有効になります。上記の「履歴の簡素化」を参照してください。

--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> を指定すると、デフォルトのものに代わって表示される文字列になります。

出力

競合がない場合、このコマンドの出力をgit update-ref --stdin の入力として使用できます。形式は次のとおりです。

update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH}

更新される参照の数は、渡された引数と再生される履歴の形状によって異なります。--advance を使用する場合、更新される参照の数は常に1つですが、--onto の場合は1つ以上になる場合があります(複数のブランチを同時にリベースすることがサポートされています)。

終了ステータス

成功し、競合のない再生の場合、終了ステータスは0です。再生に競合がある場合、終了ステータスは1です。何らかのエラーのために再生が完了できない(または開始できない)場合、終了ステータスは0または1以外になります。

mybranchtarget に単純にリベースするには

$ git replay --onto target origin/main..mybranch
update refs/heads/mybranch ${NEW_mybranch_HASH} ${OLD_mybranch_HASH}

mybranch からのコミットを target にチェリーピックするには

$ git replay --advance target origin/main..mybranch
update refs/heads/target ${NEW_target_HASH} ${OLD_target_HASH}

最初の2つの例は、まったく同じコミットをまったく同じ新しいベースの上に再生するという点で同じですが、最初の例は mybranch が新しいコミットを指すように指示し、2番目の例は target が新しいコミットを指すように指示するという点で異なります。

ブランチのスタックがあり、互いに依存しており、セット全体をリベースしたい場合はどうすればよいですか?

$ git replay --contained --onto origin/main origin/main..tipbranch
update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
update refs/heads/tipbranch ${NEW_tipbranch_HASH} ${OLD_tipbranch_HASH}

git replay を呼び出す場合、A..B 構文を使用して再生するコミットの範囲を指定する必要はありません。任意の範囲式で機能します。

$ git replay --onto origin/main ^base branch1 branch2 branch3
update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH}

これにより、branch1branch2branch3 が同時にリベースされ、それらがbase以降に持っているすべてのコミットがorigin/mainの上に再生されます。これらの3つのブランチは、baseの上に共通のコミットを持っている可能性がありますが、必ずしもそうである必要はありません。

Git

git[1] スイートの一部

scroll-to-top