セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ適用
デバッグ
メール
外部システム
サーバー管理
- 2.50.1 変更なし
-
2.50.0
2025-06-16
- 2.49.1 変更なし
-
2.49.0
2025-03-14
- 2.48.1 → 2.48.2 変更なし
-
2.48.0
2025-01-10
- 2.45.1 → 2.47.3 変更なし
-
2.45.0
2024-04-29
- 2.44.1 → 2.44.4 変更なし
-
2.44.0
2024-02-23
概要
(EXPERIMENTAL!) git replay ([--contained] --onto <newbase> | --advance <branch>) <revision-range>…
説明
コミットの範囲を取り、新しい場所にリプレイします。作業ツリーとインデックスは変更せず、参照も更新しません。このコマンドの出力は、関連するブランチを更新する git
update-ref
--stdin
への入力として使用されることを意図しています (以下の OUTPUT セクションを参照)。
このコマンドは実験的です。動作が変更される可能性があります。
オプション
- --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/committer ヘッダー行を持つコミットに出力を制限します。複数の
--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/
で始まらなければなりません。末尾に /* を意図する場合は、明示的に与える必要があります。 -
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
-
コミットのセットが対称差で制限されている場合、別のコミットと同じ変更を導入するコミットを「反対側」から省略します。
たとえば、2つのブランチ
A
とB
がある場合、それらの片側にのみ存在するすべてのコミットをリストする一般的な方法は--left-right
を使用することです (--left-right
オプションの説明の以下の例を参照)。ただし、これは他のブランチから cherry-pick されたコミットを示します (たとえば、「3rd on b」はブランチ A から cherry-pick された可能性があります)。このオプションを使用すると、このようなコミットのペアは出力から除外されます。 - --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
-
コミットの祖先チェーンを辿る代わりに、最新のエントリから古いエントリへと reflog エントリを辿ります。このオプションを使用する場合、除外するコミット (つまり、^commit、commit1..commit2、および commit1...commit2 の表記は使用できません) を指定することはできません。
oneline
およびreference
以外の--pretty
形式 (明らかな理由から) を使用すると、出力には reflog から取得された情報が 2 行追加されます。出力の reflog 指示子は、いくつかのルールに従ってref@{
<Nth>}
(<Nth> は reflog の逆時系列インデックス) またはref@{
<timestamp>}
(そのエントリの <timestamp>) として表示される場合があります。-
開始点が
ref@{
<Nth>}
として指定されている場合、インデックス形式を表示します。 -
開始点が
ref@{now}
として指定された場合、タイムスタンプ形式を表示します。 -
どちらも使用されなかったが、コマンドラインで
--date
が指定された場合、--date
で要求された形式でタイムスタンプを表示します。 -
それ以外の場合、インデックス形式を表示します。
--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つはそれをどのように行うかであり、履歴を簡素化するための様々な戦略があります。
次のオプションは、表示するコミットを選択します。
意味のある履歴を提供するために、追加のコミットが表示される場合があることに注意してください。
以下のオプションは、簡素化の実行方法に影響します。
- デフォルトモード
-
ツリーの最終状態を説明する最も単純な履歴に履歴を簡素化します。最も単純とは、最終結果が同じである場合 (つまり、同じ内容のブランチをマージする場合) に一部のサイドブランチをプルーニングするためです。
- --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
でフィルタリングされた 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
が削除されました。なぜなら、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 としてマークされます (簡素化の対象となります)。
コミットの順序付け
デフォルトでは、コミットは逆時系列順に表示されます。
- --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 2 1。--topo-order
を使用すると、8 6 5 3 7 4 2 1 (または 8 7 4 2 6 5 3 1) と表示されます。これは、2つの並行開発トラックからのコミットが混ざって表示されるのを避けるために、古いコミットが新しいコミットの前に表示される場合があります。 - --reverse
-
表示されるように選択されたコミット (上記のコミット制限セクションを参照) を逆順で出力します。
--walk-reflogs
と組み合わせることはできません。
コミットの書式設定
- --pretty[=<format>]
- --format=<format>
-
指定された形式でコミットログの内容を整形して表示します。ここで <format> は、oneline、short、medium、full、fuller、reference、email、raw、format:<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スペースでインデントする整形形式 (つまり、デフォルトである medium、full、および fuller) ではタブが展開されます。
- --notes[=<ref>]
-
コミットログメッセージを表示するときに、コミットに注釈を付けるノート (git-notes[1] を参照) を表示します。これは、コマンドラインで
--pretty
、--format
、または--oneline
オプションが指定されていない場合のgit
log
、git
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
設定変数は、log コマンドの--date
オプションのデフォルト値を設定します。デフォルトでは、日付は元のタイムゾーン (コミッターまたは作者のタイムゾーン) で表示されます。-local
が形式に追加された場合 (例:iso-local
)、代わりにユーザーのローカルタイムゾーンが使用されます。--date=relative
は、日付を現在時刻からの相対的な形式 (例: 「2 hours ago」) で表示します。-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:...
は、%s、%z、%Z を除く形式 ... をシステムstrftime
に渡します。これらは内部で処理されます。--date=format:%c
を使用して、システムロケールの優先形式で日付を表示します。書式指定子の完全なリストについては、strftime
マニュアルを参照してください。-local
を使用する場合の正しい構文は--date=format-local:...
です。--date=default
はデフォルトの形式であり、ctime(3) の出力に基づいています。3文字の曜日、3文字の月、日、"HH:MM:SS" 形式の時分秒、4桁の年、そしてタイムゾーン情報が1行で表示されます。ただし、ローカルタイムゾーンが使用される場合は例外です。例:Thu
Jan
1
00:00:00
1970
+0000
。 -
- --parents
-
コミットの親も出力します (「commit parent…」の形式)。親の書き換えも有効になります。上記の「History Simplification」を参照してください。
- --children
-
コミットの子も出力します (「commit child…」の形式)。親の書き換えも有効になります。上記の「History Simplification」を参照してください。
- --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
と組み合わせることはできません。これにより親の書き換えが有効になります。上記の「History Simplification」を参照してください。
これはデフォルトで
--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 以外になります。
例
mybranch
を target
にリベースするだけの場合
$ 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}
これは、branch1
、branch2
、branch3
のすべてを同時にリベースし、base
以降のコミットをすべて origin/main
の上に再生します。これらの3つのブランチは、base
の上に共通のコミットを持つことができますが、そうである必要はありません。
GIT
git[1]スイートの一部