Git

git-merge は 2.47.0 で最後に更新されました

NAME

git-merge - 2つ以上の開発履歴を結合する

SYNOPSIS

git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
	[--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
	[--[no-]allow-unrelated-histories]
	[--[no-]rerere-autoupdate] [-m <msg>] [-F <file>]
	[--into-name <branch>] [<commit>…]
git merge (--continue | --abort | --quit)

DESCRIPTION

指定されたコミットからの変更（それらの履歴が現在のブランチから分岐した時点以降）を現在のブランチに統合します。このコマンドは、git pullによって別のリポジトリからの変更を統合するために使用され、手動で1つのブランチから別のブランチに変更をマージするために使用できます。

以下の履歴が存在し、現在のブランチがmasterであると仮定します。

	  A---B---C topic
	 /
    D---E---F---G master

その後、git merge topicは、topicブランチでmaster（つまり、E）から分岐した時点から現在のコミット（C）までに行われた変更をmasterの上に再生し、親コミットの2つの名前と、ユーザーが変更を説明するログメッセージとともに、新しいコミットに結果を記録します。操作の前に、ORIG_HEADは現在のブランチの先端（C）に設定されます。

	  A---B---C topic
	 /         \
    D---E---F---G---H master

マージは、自動的に解決できない競合がある場合、またはマージを開始時に--no-commitが指定された場合に停止します。その時点で、git merge --abortまたはgit merge --continueを実行できます。

git merge --abortはマージプロセスを中止し、マージ前の状態を再構築しようとします。ただし、マージが開始されたときに未コミットの変更があり（特に、マージが開始された後にそれらの変更がさらに変更された場合）、git merge --abortは、いくつかのケースで元の（マージ前）の変更を再構築できません。そのため

警告: 重要な未コミットの変更がある状態でgit mergeを実行することは推奨されません。実行可能ですが、競合が発生した場合に元に戻すのが困難な状態になる可能性があります。

OPTIONS

--commit
--no-commit: マージを実行し、結果をコミットします。このオプションは、--no-commitをオーバーライドするために使用できます。

--no-commitを使用すると、マージを実行し、マージコミットを作成する直前で停止し、ユーザーがマージ結果を検査してさらに調整してからコミットする機会を与えます。

高速転送による更新ではマージコミットが作成されないため、--no-commitを使用してそれらのマージを停止することはできません。したがって、ブランチがマージコマンドによって変更または更新されないようにするには、--no-ffと--no-commitを一緒に使用します。
--edit
-e
--no-edit: 自動生成されたマージメッセージをさらに編集するために、正常に機械的にマージされた後にエディターを起動して、ユーザーがマージを説明し正当化できるようにします。--no-editオプションを使用して、自動生成されたメッセージを受け入れることができます（これは一般的に推奨されません）。コマンドラインから-mオプションでドラフトメッセージを指定し、エディターで編集したい場合は、--edit（または-e）オプションが依然として役立ちます。

古いスクリプトは、ユーザーがマージログメッセージを編集できないという従来の動作に依存している可能性があります。git mergeを実行すると、エディターが開いているのが表示されます。このようなスクリプトを更新された動作に調整しやすくするために、環境変数GIT_MERGE_AUTOEDITをスクリプトの先頭でnoに設定できます。
--cleanup=<mode>: このオプションは、コミットする前にマージメッセージがどのようにクリーンアップされるかを決定します。詳細はgit-commit[1]を参照してください。さらに、<mode>にscissorsの値が指定されている場合、マージの競合が発生した場合は、ハサミがMERGE_MSGに追加されてから、コミット機構に渡されます。
--ff
--no-ff
--ff-only: マージされた履歴が現在の履歴の派生元である場合のマージの処理方法を指定します。注釈付き（そして署名されている可能性のある）タグをrefs/tags/階層の自然な場所に保存していない場合を除いて、--ffがデフォルトです。その場合は--no-ffが想定されます。

--ffを使用すると、可能な場合は高速転送としてマージを解決します（ブランチポインターをマージされたブランチと一致するように更新するだけで、マージコミットは作成しません）。不可能な場合（マージされた履歴が現在の履歴の派生元でない場合）は、マージコミットを作成します。

--no-ffを使用すると、マージを高速転送として解決できる場合でも、常にマージコミットを作成します。

--ff-onlyを使用すると、可能な場合はマージを高速転送として解決します。不可能な場合は、マージを拒否し、ゼロ以外のステータスで終了します。
-S[<keyid>]
--gpg-sign[=<keyid>]
--no-gpg-sign: 結果のマージコミットにGPG署名します。keyid引数はオプションで、コミッターIDがデフォルトです。指定する場合は、スペースを入れずにオプションに貼り付ける必要があります。--no-gpg-signは、commit.gpgSign構成変数と、以前の--gpg-signの両方を無効にするために役立ちます。
--log[=<n>]
--no-log: ブランチ名に加えて、マージされている実際のコミットのうち最大<n>個からの1行の説明をログメッセージに入力します。git-fmt-merge-msg[1]も参照してください。

--no-logを使用すると、マージされている実際のコミットからの1行の説明はリストされません。
--signoff
--no-signoff: コミットログメッセージの最後に、コミッターによるSigned-off-byトレーラーを追加します。サインオフの意味は、コミット先のプロジェクトによって異なります。たとえば、コミッターがプロジェクトのライセンスに基づいて作業を提出する権利を持っていること、または開発者証明書などの貢献者の表現に同意することを証明する場合があります。（LinuxカーネルとGitプロジェクトで使用されているものについては、https://developercertificate.orgを参照してください。）貢献するプロジェクトのドキュメントまたはリーダーシップを参照して、そのプロジェクトでサインオフがどのように使用されているかを理解してください。

--no-signoffオプションを使用して、コマンドラインで前の--signoffオプションを無効にすることができます。
--stat
-n
--no-stat: マージの最後にdiffstatを表示します。diffstatは、構成オプションmerge.statによっても制御されます。

-nまたは--no-statを使用すると、マージの最後にdiffstatは表示されません。
--squash
--no-squash: 実際のマージが行われた場合と同じワークツリーとインデックスの状態を生成します（マージ情報以外）。ただし、実際にコミットを作成したり、HEADを移動したり、$GIT_DIR/MERGE_HEADを記録したりしません（次のgit commitコマンドでマージコミットが作成されるのを防ぐためです）。これにより、現在のブランチの先頭に、別のブランチをマージした場合と同じ効果を持つ単一のコミットを作成できます（オクトパスマージの場合は複数ブランチ）。

--no-squash オプションを使用すると、マージを実行し、その結果をコミットします。このオプションは--squashを無効にするために使用できます。

--squash オプションを使用する場合、--commit オプションは許可されず、エラーになります。
--[no-]verify: デフォルトでは、pre-mergeフックとcommit-msgフックが実行されます。--no-verify オプションを指定すると、これらのフックはバイパスされます。githooks[5]も参照してください。
-s <strategy>
--strategy=<strategy>: 指定されたマージ戦略を使用します。複数回指定して、試行する順番を指定できます。-s オプションがない場合は、ビルトインの戦略リストが代わりに使用されます（単一ヘッドのマージの場合はort、それ以外の場合はoctopus）。
-X <option>
--strategy-option=<option>: マージ戦略に固有のオプションをマージ戦略に渡します。
--verify-signatures
--no-verify-signatures: マージされるサイドブランチの先端コミットが有効なキーで署名されていることを検証します（つまり、有効なuidを持つキー）。デフォルトの信頼モデルでは、これは署名キーが信頼できるキーによって署名されていることを意味します。サイドブランチの先端コミットが有効なキーで署名されていない場合、マージは中止されます。
--summary
--no-summary: --statおよび--no-statの同義語です。これらは非推奨であり、将来削除されます。
-q
--quiet: 静かに動作します。--no-progressを意味します。
-v
--verbose: 詳細情報を表示します。
--progress
--no-progress: 進捗状況の表示を明示的にオン/オフします。どちらも指定しない場合、標準エラーが端末に接続されている場合に進捗状況が表示されます。すべてのマージ戦略が進捗状況の報告をサポートするとは限りません。
--autostash
--no-autostash: 操作開始前に一時的なstashエントリを自動的に作成し、MERGE_AUTOSTASH refに記録し、操作終了後に適用します。これは、ダーティなワークツリーで操作を実行できることを意味します。ただし、注意して使用してください。成功したマージ後の最終的なstashの適用により、複雑な競合が発生する可能性があります。
--allow-unrelated-histories: デフォルトでは、git mergeコマンドは共通の祖先を共有しない履歴のマージを拒否します。このオプションは、独立して開始された2つのプロジェクトの履歴をマージする場合に、この安全性を無効にするために使用できます。これは非常にまれなケースであるため、デフォルトでこれを有効にするための設定変数は存在せず、追加されることもありません。
-m <msg>: マージコミット（作成された場合）に使用するコミットメッセージを設定します。

--logが指定されている場合、マージされるコミットのshortlogが指定されたメッセージに追加されます。

git fmt-merge-msgコマンドを使用して、自動化されたgit merge呼び出しの適切なデフォルト値を設定できます。自動生成されたメッセージには、ブランチの説明を含めることができます。
--into-name <branch>: マージが行われた実際のブランチの名前ではなく、ブランチ<branch>にマージする場合と同じように、デフォルトのマージメッセージを準備します。
-F <file>
--file=<file>: マージコミット（作成された場合）に使用するコミットメッセージを読み込みます。

--logが指定されている場合、マージされるコミットのshortlogが指定されたメッセージに追加されます。
--rerere-autoupdate
--no-rerere-autoupdate: rerereメカニズムが現在の競合に関する記録された解決策を再利用してワークツリーのファイルを更新した後、その解決策の結果でインデックスも更新することを許可します。--no-rerere-autoupdateは、rerereが行ったことを二重チェックし、潜在的な誤ったマージを検出し、別々のgit addで結果をインデックスにコミットする前に、良い方法です。
--overwrite-ignore
--no-overwrite-ignore: マージ結果から無視されたファイルをサイレントに上書きします。これがデフォルトの動作です。中止するには--no-overwrite-ignoreを使用します。
--abort: 現在の競合解決プロセスを中止し、マージ前の状態を再構築しようとします。autostashエントリが存在する場合は、ワークツリーに適用します。

マージ開始時にコミットされていないワークツリーの変更が存在する場合、git merge --abortは、場合によってはこれらの変更を再構築できない場合があります。したがって、git mergeを実行する前に、常に変更をコミットまたはstashすることをお勧めします。

MERGE_HEADが存在する場合、git merge --abortはgit reset --mergeと同等です。ただし、MERGE_AUTOSTASHも存在する場合は、git merge --abortはstashエントリをワークツリーに適用しますが、git reset --mergeはstashされた変更をstashリストに保存します。
--quit: 進行中のマージを忘れます。インデックスとワークツリーはそのままにします。MERGE_AUTOSTASHが存在する場合は、stashエントリがstashリストに保存されます。
--continue: 競合のためにgit mergeが停止した後、git merge --continueを実行してマージを完了できます（以下の「競合の解決方法」セクションを参照）。
<commit>…: 通常は他のブランチヘッドであるコミットを、私たちのブランチにマージします。複数のコミットを指定すると、2つ以上の親を持つマージ（オクトパスマージと呼ばれます）が作成されます。

コマンドラインからコミットが指定されていない場合、現在のブランチが上流ブランチとして使用するように構成されているリモートトラッキングブランチをマージします。このマニュアルページの設定セクションも参照してください。

FETCH_HEAD（および他のコミットなし）が指定されている場合、前のgit fetch呼び出しによってマージのために.git/FETCH_HEADファイルに記録されたブランチが現在のブランチにマージされます。

マージ前のチェック

外部からの変更を適用する前に、自分の作業を適切に整理してローカルにコミットする必要があります。これにより、競合が発生した場合でも上書きされません。git-stash[1]も参照してください。git pullとgit mergeは、ローカルのコミットされていない変更がgit pull/git mergeが更新する必要があるファイルと重複している場合、何もせずに停止します。

マージコミットに関連のない変更を記録しないようにするために、git pullとgit mergeは、HEADコミットに対してインデックスに登録されている変更がある場合も中止します。（使用されているマージ戦略によっては、この規則に特別な狭い例外が存在する場合がありますが、一般的に、インデックスはHEADと一致する必要があります。）

名前付きコミットがすべて既にHEADの祖先である場合、git mergeは「既に最新です」というメッセージで早期に終了します。

高速フォワードマージ

多くの場合、現在のブランチヘッドは名前付きコミットの祖先です。これは、特にgit pullから呼び出された場合、最も一般的なケースです。上流のリポジトリを追跡しており、ローカルの変更をコミットしておらず、新しい上流のリビジョンに更新したい場合です。この場合、結合された履歴を保存するために新しいコミットは必要ありません。代わりに、追加のマージコミットを作成せずに、HEAD（インデックスを含む）が名前付きコミットを指すように更新されます。

この動作は--no-ffオプションで抑制できます。

真のマージ

高速フォワードマージ（上記参照）を除き、マージするブランチは、両方を親とするマージコミットによって結び付けられている必要があります。

マージするすべてのブランチからの変更を調整したマージされたバージョンがコミットされ、HEAD、インデックス、ワークツリーがそれに更新されます。重複しない限り、ワークツリーに変更を加えることが可能です。更新によってそれらは保持されます。

変更を調整する方法が明確でない場合、次のことが発生します。

HEADポインタは同じままです。
MERGE_HEAD refは、別のブランチヘッドを指すように設定されます。
クリーンにマージされたパスは、インデックスファイルとワークツリーの両方で更新されます。
競合するパスについては、インデックスファイルに最大3つのバージョンが記録されます。ステージ1には共通の祖先からのバージョン、ステージ2にはHEADからのバージョン、ステージ3にはMERGE_HEADからのバージョンが格納されます（git ls-files -uでステージを検査できます）。ワークツリーファイルには、マージ操作の結果が含まれます。つまり、おなじみの競合マーカー<<< === >>>を含む3方向マージの結果です。
AUTO_MERGEという名前のrefが書き込まれ、ワークツリーの現在のコンテンツ（テキストの競合のマーカーを含む）に対応するツリーを指します。このrefは、ortマージ戦略（デフォルト）が使用されている場合にのみ書き込まれます。
その他の変更は行われません。特に、マージを開始する前に持っていたローカルの変更は同じままで、それらのインデックスエントリはHEADと一致したままです。

複雑な競合が発生したマージを試行し、やり直したい場合は、git merge --abortで復旧できます。

タグのマージ

注釈付き（そして署名されている可能性のある）タグをマージする場合、Gitは高速フォワードマージが可能であっても常にマージコミットを作成し、コミットメッセージテンプレートはタグメッセージで準備されます。さらに、タグが署名されている場合、署名チェックはメッセージテンプレートのコメントとして報告されます。git-tag[1]も参照してください。

タグ付けされたコミットに至る作業を統合したい場合（例：上流のリリース時点との同期）は、不要なマージコミットを作成したくない場合があります。

そのような場合、git mergeに渡す前に自分でタグを「展開」するか、独自の作業がない場合は--ff-onlyを渡すことができます。例：

git fetch origin
git merge v1.2.3^0
git merge --ff-only v1.2.3

競合の表示方法

マージ中に、作業ツリーのファイルはマージ結果を反映するように更新されます。共通の先祖のバージョンに加えられた変更のうち、重複しない変更（つまり、一方だけがファイルのある領域を変更し、もう一方はその領域をそのまま残した場合）は、最終結果にそのまま組み込まれます。しかし、両方が同じ領域を変更した場合、Gitは一方を一方を無作為に選択することはできず、両方の変更をその領域に残して解決するよう求めます。

デフォルトでは、GitはRCSスイートの「merge」プログラムで使用されているものと同じスタイルを使用して、このような競合する部分を提示します。例：

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
or cleanly resolved because both sides changed the same way.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

一対の競合する変更が発生した領域は、マーカー<<<<<<<、=======、および>>>>>>>でマークされています。=======の手前の部分は通常自分の側の変更、後の部分は通常相手側の変更です。

デフォルトの形式では、競合領域の元の状態は表示されません。自分の側の変更で何行が削除され、バービーのコメントで置き換えられたかは分かりません。分かるのは、自分の側は難しいと言いたいので買い物に行きたいと思っているのに対し、相手側は簡単だと主張したいと思っているということです。

merge.conflictStyle設定変数を「diff3」または「zdiff3」のいずれかに設定することで、代替スタイルを使用できます。「diff3」スタイルでは、上記の競合は次のようになります。

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
<<<<<<< yours:sample.txt
or cleanly resolved because both sides changed the same way.
Conflict resolution is hard;
let's go shopping.
||||||| base:sample.txt
or cleanly resolved because both sides changed identically.
Conflict resolution is hard.
=======
or cleanly resolved because both sides changed the same way.
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

一方、「zdiff3」スタイルでは、次のようになります。

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
or cleanly resolved because both sides changed the same way.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
||||||| base:sample.txt
or cleanly resolved because both sides changed identically.
Conflict resolution is hard.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

<<<<<<<、=======、および>>>>>>>マーカーに加えて、元のテキストが続く別の|||||||マーカーを使用します。元の文章は単なる事実の記述であり、自分の側はそれに従って諦めたのに対し、相手側はより肯定的な態度を取ろうとしたことが分かります。元の文章を参照することで、より良い解決策を思いつくことがあります。

競合の解決方法

競合が発生したら、2つのことができます。

マージしないことを決定します。必要なクリーンアップは、インデックスファイルをHEADコミットにリセットして2.を元に戻し、2.と3.によって行われた作業ツリーの変更をクリーンアップすることです。これにはgit merge --abortを使用できます。
競合を解決します。Gitは作業ツリー内の競合をマークします。ファイルを編集して整形し、git addでインデックスに追加します。git commitまたはgit merge --continueを使用して処理を完了します。後者のコマンドは、git commitを呼び出す前に、（中断された）マージが進行中かどうかを確認します。

いくつかのツールを使用して競合を解決できます。

マージツールを使用する。git mergetoolを使用してグラフィカルなマージツールを起動し、マージを処理します。
差分を確認する。git diffは3方向の差分を表示し、HEADバージョンとMERGE_HEADバージョンの両方の変更を強調表示します。git diff AUTO_MERGEは、テキストの競合を解決するためにこれまでに行った変更を示します。
各ブランチからの差分を確認する。git log --merge -p <path>は、まずHEADバージョンの差分、次にMERGE_HEADバージョンの差分を表示します。
元のファイルを確認する。git show :1:filenameは共通の先祖、git show :2:filenameはHEADバージョン、git show :3:filenameはMERGE_HEADバージョンを表示します。

例

現在のブランチの上にfixesブランチとenhancementsブランチをマージして、オクトパスマージを作成します。
```
$ git merge fixes enhancements
```
oursマージ戦略を使用して、obsoleteブランチを現在のブランチにマージします。
```
$ git merge -s ours obsolete
```
maintブランチを現在のブランチにマージしますが、新しいコミットを自動的に作成しません。
```
$ git merge --no-commit maint
```
これは、マージにさらに変更を含めたい場合、または独自のコミットメッセージを作成したい場合に使用できます。

このオプションを乱用して、大幅な変更をマージコミットにこっそり含めることは避けるべきです。リリース/バージョンの名前の変更などの小さな修正は許容されます。

マージ戦略

マージメカニズム（git mergeおよびgit pullコマンド）では、バックエンドのマージ戦略を-sオプションで選択できます。一部の戦略では、独自のオプションも使用できます。これらは、git mergeおよび/またはgit pullに-X<option>引数を渡すことで渡すことができます。

ort

これは、1つのブランチをプルまたはマージする場合のデフォルトのマージ戦略です。この戦略は、3方向マージアルゴリズムを使用して2つのヘッドのみを解決できます。3方向マージに使用できる共通の先祖が複数ある場合、共通の先祖の結合ツリーを作成し、それを3方向マージの参照ツリーとして使用します。これは、Linux 2.6カーネル開発履歴から取得された実際のマージコミットで実行されたテストにより、誤ったマージを引き起こすことなく、マージの競合を削減できることが報告されています。さらに、この戦略は、名前変更を含むマージを検出して処理できます。検出されたコピーは使用しません。このアルゴリズムの名前は頭字語（「Ostensibly Recursive’s Twin」）であり、以前のデフォルトアルゴリズムであるrecursiveの置き換えとして記述されたという事実から来ています。

ort戦略では、次のオプションを使用できます。

ours

このオプションは、自分のバージョンを優先することで、競合する部分をクリーンに自動解決します。自分側の変更と競合しない相手側の変更は、マージ結果に反映されます。バイナリファイルの場合、内容はすべて自分側のものになります。

これは、oursマージ戦略と混同しないでください。oursマージ戦略は、相手側のツリーの内容をまったく見ません。相手側のツリーで行われたすべての変更を破棄し、自分の履歴にすべてが含まれていると宣言します。

theirs

これはoursの反対です。oursとは異なり、このマージオプションと混同するtheirsマージ戦略がないことに注意してください。

ignore-space-change

ignore-all-space

ignore-space-at-eol

ignore-cr-at-eol

3方向マージのために、指定されたタイプの空白の変更を含む行を未変更として扱います。他の変更と混在した空白の変更は無視されません。git-diff[1]の-b、-w、--ignore-space-at-eol、および--ignore-cr-at-eolも参照してください。

相手側のバージョンが空白の変更のみを行っている場合、自分側のバージョンが使用されます。
自分側のバージョンが空白の変更を行っているが、相手側のバージョンが大幅な変更を含む場合、相手側のバージョンが使用されます。
それ以外の場合は、通常どおりマージが実行されます。

renormalize

3方向マージの解決時に、ファイルの3つのステージすべてに対して仮想的なチェックアウトとチェックインを実行します。このオプションは、異なるクリーンフィルターまたは改行の正規化ルールを持つブランチをマージする場合に使用することを目的としています。gitattributes[5]の「チェックイン/チェックアウト属性が異なるブランチのマージ」の詳細を参照してください。

no-renormalize

renormalizeオプションを無効にします。これはmerge.renormalize設定変数をオーバーライドします。

find-renames[=<n>]

名前変更の検出を有効にし、必要に応じて類似性のしきい値を設定します。これはデフォルトです。これはmerge.renames設定変数をオーバーライドします。git-diff[1]の--find-renamesも参照してください。

rename-threshold=<n>

find-renames=<n>の非推奨の同義語です。

subtree[=<path>]

このオプションは、subtree戦略のより高度な形式であり、戦略はマージ時に2つのツリーを一致させるためにどのようにシフトする必要があるかを推測します。代わりに、指定されたパスが接頭辞として追加されるか（または先頭から削除される）ことで、2つのツリーの形状を一致させます。

recursive

これは、3方向マージアルゴリズムを使用して2つのヘッドのみを解決できます。3方向マージに使用できる共通の先祖が複数ある場合、共通の先祖の結合ツリーを作成し、それを3方向マージの参照ツリーとして使用します。これは、Linux 2.6カーネル開発履歴から取得された実際のマージコミットで実行されたテストにより、誤ったマージを引き起こすことなく、マージの競合を削減できることが報告されています。さらに、これは名前変更を含むマージを検出して処理できます。検出されたコピーは使用しません。これは、Git v0.99.9kからv2.33.0まで、2つのヘッドを解決するためのデフォルトの戦略でした。

recursive戦略は、ortと同じオプションを受け取ります。ただし、ortが無視する（上記に記載されていない）追加の3つのオプションがあり、recursive戦略で役立つ可能性があります。

patience: diff-algorithm=patienceの非推奨の同義語です。
diff-algorithm=[patience|minimal|histogram|myers]: マージ中に異なる差分アルゴリズムを使用します。これにより、重要ではない一致する行（異なる関数の括弧など）が原因で発生する誤ったマージを回避できます。git-diff[1]の--diff-algorithmも参照してください。ortは特にdiff-algorithm=histogramを使用しますが、recursiveはデフォルトでdiff.algorithm設定を使用することに注意してください。
no-renames: 名前変更の検出を無効にします。これはmerge.renames設定変数をオーバーライドします。git-diff[1]の--no-renamesも参照してください。

resolve

これは、3方向マージアルゴリズムを使用して2つのヘッド（つまり、現在のブランチとプルした別のブランチ）のみを解決できます。ジグザグマージの曖昧さを慎重に検出しようとします。名前変更は処理しません。

octopus

これは2つ以上のヘッドを持つケースを解決しますが、手動での解決が必要な複雑なマージは拒否します。これは主に、トピックブランチのヘッドをまとめてバンドルするために使用することを目的としています。これは、2つ以上のブランチをプルまたはマージする場合のデフォルトのマージ戦略です。

ours

これは任意の数のヘッドを解決しますが、マージの結果ツリーは常に現在のブランチヘッドのツリーであり、他のすべてのブランチからのすべての変更を効果的に無視します。これは、サイドブランチの古い開発履歴を置き換えるために使用することを目的としています。これは、recursiveマージ戦略の-Xoursオプションとは異なることに注意してください。

subtree

これは修正されたort戦略です。ツリーAとBをマージする場合、BがAのサブツリーに対応している場合、同じレベルでツリーを読み取るのではなく、まずBを調整してAのツリー構造と一致させます。この調整は、共通の先祖ツリーにも行われます。

3方向マージを使用する戦略（デフォルトのortを含む）では、両方のブランチで変更が行われ、後で一方のブランチで元に戻された場合、その変更はマージ結果に存在します。一部の人は、この動作を分かりにくいと感じています。これは、マージを実行する際に、個々のコミットではなく、ヘッドとマージベースのみが考慮されるためです。したがって、マージアルゴリズムは元に戻された変更をまったく変更がないものと見なし、代わりに変更されたバージョンを代用します。

設定

branch.<name>.mergeOptions: ブランチ<name>へのマージのデフォルトオプションを設定します。構文とサポートされるオプションはgit mergeと同じですが、空白文字を含むオプション値は現在サポートされていません。

このセクションの上記のすべての行は、git-config[1]のドキュメントから含まれていません。以下の内容は、そこに記載されているものと同じです。

merge.conflictStyle

マージ時に、競合が発生したハンクをワーキングツリーファイルに出力するスタイルを指定します。デフォルトは「merge」で、<<<<<<< の競合マーカー、一方の変更、======= マーカー、もう一方の変更、そして >>>>>>> マーカーが表示されます。「diff3」という代替スタイルでは、||||||| マーカーと======= マーカーの前に元のテキストが追加されます。「merge」スタイルは、元のテキストを含めないことと、両側で部分的な行が一致する場合に競合領域から削除されるため、diff3よりも小さな競合領域になる傾向があります。もう1つの代替スタイルである「zdiff3」はdiff3に似ていますが、競合領域の先頭または末尾付近にある2つの側で一致する行は競合領域から削除されます。

merge.defaultToUpstream

コミット引数なしでマージが呼び出された場合、現在のブランチに対して設定された上流ブランチを、それらのリモート追跡ブランチに保存されている最後に観察された値を使用してマージします。branch.<current branch>.merge の値（branch.<current branch>.remote で指定されたリモートにあるブランチの名前）を参照し、次に remote.<remote>.fetch を介して対応するリモート追跡ブランチにマッピングし、これらの追跡ブランチの先端をマージします。デフォルトはtrueです。

merge.ff

デフォルトでは、Gitは、現在のコミットの子孫であるコミットをマージする場合に、追加のマージコミットを作成しません。代わりに、現在のブランチの先端が高速転送されます。falseに設定すると、この変数はGitにそのような場合に追加のマージコミットを作成するように指示します（コマンドラインから--no-ffオプションを指定した場合と同じです）。onlyに設定すると、そのような高速転送マージのみが許可されます（コマンドラインから--ff-onlyオプションを指定した場合と同じです）。

merge.verifySignatures

trueの場合、これは--verify-signaturesコマンドラインオプションと同じです。詳細はgit-merge[1]を参照してください。

merge.branchdesc

ブランチ名に加えて、ブランチ名に関連付けられたブランチの説明テキストをログメッセージに含めます。デフォルトはfalseです。

merge.log

ブランチ名に加えて、マージされている実際のコミットから、最大指定された数の1行の説明をログメッセージに含めます。デフォルトはfalseで、trueは20と同義です。

merge.suppressDest

この複数値の構成変数に、統合ブランチの名前と一致するglobを追加することにより、これらの統合ブランチへのマージに対して計算されたデフォルトのマージメッセージから、「into <branch name>」というタイトルが省略されます。

空の値を持つ要素を使用して、以前の構成エントリから累積されたglobのリストをクリアできます。merge.suppressDest変数が定義されていない場合、後方互換性のためにデフォルト値のmasterが使用されます。

merge.renameLimit

マージ中にリネーム検出の網羅的な部分で考慮するファイルの数です。指定されていない場合、diff.renameLimitの値がデフォルトになります。merge.renameLimitとdiff.renameLimitのどちらも指定されていない場合、現在デフォルトは7000です。リネーム検出が無効になっている場合、この設定は効果がありません。

merge.renames

Gitがリネームを検出するかどうか。 "false"に設定すると、リネーム検出は無効になります。"true"に設定すると、基本的なリネーム検出が有効になります。diff.renamesの値がデフォルトになります。

merge.directoryRenames

Gitがディレクトリの移動を検出するかどうか。履歴の一方の側でディレクトリがリネームされた場合に、履歴のもう一方の側でそのディレクトリに追加された新しいファイルに、マージ時に何が起こるかを決定します。merge.directoryRenamesが"false"に設定されている場合、ディレクトリのリネーム検出は無効になります。つまり、そのような新しいファイルは古いディレクトリに残されます。"true"に設定されている場合、ディレクトリのリネーム検出が有効になります。つまり、そのような新しいファイルは新しいディレクトリに移動されます。"conflict"に設定されている場合、そのようなパスに対して競合が報告されます。merge.renamesがfalseの場合、merge.directoryRenamesは無視され、falseとして扱われます。デフォルトは"conflict"です。

merge.renormalize

リポジトリ内のファイルの標準表現が時間とともに変化したことをGitに伝えます（例：以前のコミットはCRLF改行でテキストファイルを記録していましたが、最近のものはLF改行を使用しています）。このようなリポジトリでは、Gitは、マージを実行する前にコミットに記録されたデータを標準形式に変換して、不要な競合を減らすことができます。詳細については、gitattributes[5]の「チェックイン/チェックアウト属性が異なるブランチのマージ」セクションを参照してください。

merge.stat

マージの最後に、ORIG_HEADとマージ結果の間のdiffstatを出力するかどうか。デフォルトでTrue。

merge.autoStash

trueに設定すると、操作開始前に一時的なstashエントリを自動的に作成し、操作終了後に適用します。これは、ダーティなワークツリーでマージを実行できることを意味します。ただし、注意して使用してください。成功したマージ後の最終的なstashの適用により、重大な競合が発生する可能性があります。このオプションは、git-merge[1]の--no-autostashおよび--autostashオプションで上書きできます。デフォルトはfalseです。

merge.tool

git-mergetool[1]で使用されるマージツールを制御します。以下に、有効な組み込み値を示します。その他の値はカスタムマージツールとして扱われ、対応するmergetool.<tool>.cmd変数が定義されている必要があります。

merge.guitool

-g/--guiフラグが指定されている場合、git-mergetool[1]で使用されるマージツールを制御します。以下に、有効な組み込み値を示します。その他の値はカスタムマージツールとして扱われ、対応するmergetool.<guitool>.cmd変数が定義されている必要があります。

araxis
bc
codecompare
deltawalker
diffmerge
diffuse
ecmerge
emerge
examdiff
guiffy
gvimdiff
kdiff3
meld
nvimdiff
opendiff
p4merge
smerge
tkdiff
tortoisemerge
vimdiff
vscode
winmerge
xxdiff

merge.verbosity

再帰的マージ戦略によって表示される出力量を制御します。レベル0は、競合が検出された場合に最終的なエラーメッセージ以外何も出力しません。レベル1は競合のみを出力し、2は競合とファイルの変更を出力します。レベル5以上はデバッグ情報を出力します。デフォルトはレベル2です。GIT_MERGE_VERBOSITY環境変数で上書きできます。

merge.<driver>.name

カスタム低レベルマージドライバの分かりやすい名前を定義します。詳細はgitattributes[5]を参照してください。

merge.<driver>.driver

カスタム低レベルマージドライバを実装するコマンドを定義します。詳細はgitattributes[5]を参照してください。

merge.<driver>.recursive

共通の先祖間の内部マージを実行する際に使用する低レベルマージドライバの名前を指定します。詳細はgitattributes[5]を参照してください。

参照

git-fmt-merge-msg[1]、git-pull[1]、gitattributes[5]、git-reset[1]、git-diff[1]、git-ls-files[1]、git-add[1]、git-rm[1]、git-mergetool[1]

git[1]スイートの一部

セットアップと設定

プロジェクトの取得と作成

基本的なスナップショット

ブランチとマージ

プロジェクトの共有と更新

検査と比較

パッチ

デバッグ

メール

外部システム

サーバー管理

ガイド

管理

内部コマンド