コマンド名

「git-merge」：2つ以上の開発履歴を統合

概要

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>] [<commit>…]
git merge (--continue | --abort | --quit)

説明

名前付きコミットからの変更を（履歴が現在のブランチから分岐したため）現在のブランチに組み込みます。このコマンドは別のリポジトリからの変更を組み込むために「git pull」によって使用され、あるブランチから別のブランチに変更をマージするために手動で使用できます。

次の履歴が存在し、現在のブランチが「master」であると想定します。

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

次に「git merge topic」はtopicブランチがmaster（つまりE）から分岐してから現在のコミット（C）までmaster上で行われた変更を再生し、その結果を2つのペアレントコミットと変更を説明するユーザーからのログメッセージの名前とともに新しいコミットに記録します。

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

2番目のシンタックス（ ” git merge --abort “）はマージによってコンフリクトが発生した後にのみ実行できます。「git merge –abort」はマージプロセスを中止し、マージ前の状態を再構築します。ただし、マージの開始時にコミットされていない変更があった場合（特にマージの開始後にそれらの変更がさらに変更された場合）、「git merge –abort」はオリジナルの（マージ前の）変更を再構築できない場合があります。

注意：重要なコミットされていない変更を使用して「git merge」を実行することはお勧めしません。可能ではありますが、コンフリクトが発生した場合に元に戻すのが難しい状態になる可能性があります。

3番目のシンタックス（ ” git merge --continue “）はマージによってコンフリクトが発生した後にのみ実行できます。

オプション

オプション

--commit
--no-commit

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

「–no-commit」を使用すると、マージを実行し、マージコミットを作成する直前に停止し、コミットする前にマージ結果を検査し、さらに微調整する機会をユーザーに提供します。

ファーストフォワードアップデートではマージコミットが作成されないため、「-no-commit」を使用してこれらのマージを停止する方法はないことに注意してください。したがって、マージコマンドによってブランチが変更または更新されないようにする場合、「-no-ff」と「–no-commit」を使用します。

--edit
-e
--no-edit

正常な機械的マージをコミットする前にエディターを呼び出し、自動作成されたマージメッセージをさらに編集し、ユーザーがマージについて説明し、正当化できるようにします。--no-editオプションを使用し、自動作成されたメッセージを受け入れることができます（これは一般的に推奨されていません）。--edit （または-e）オプションはコマンドラインから-mオプションを指定してドラフトメッセージを表示し、エディターで編集する場合にも役立ちます。

古いスクリプトはユーザーがマージログメッセージを編集できないようにするという過去の動作に依存する場合があります。git mergeを実行すると、エディターが開きます。このようなスクリプトを更新された動作に合わせて調整しやすくするために、環境変数GIT_MERGE_AUTOEDITをスクリプトの先頭でno に設定できます。

--cleanup=<mode>

このオプションはコミットする前にマージメッセージをクリーンアップする方法を決定します。詳細についてはgit-commit[1] を参照してください。 さらに「<mode>」にscissors値が指定されている場合、マージのコンフリクトが発生した場合、シザーズがMERGE_MSG に追加されてから、コミットにパスされます。

--ff
--no-ff
--ff-only

マージされた履歴がすでに現在の履歴の子孫である場合、マージがどのように処理されるかを指定します。--ff はrefs/tags/ 階層の自然な場所に格納されていない注釈付き（および場合によっては署名済み）タグをマージしない限り、デフォルトとなっています。この場合、--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

コミットログメッセージの最後にコミッターによるサインオフラインを追加します。サインオフの意味はプロジェクトによって異なりますが、通常、コミッターが同じライセンスの下でこのワークを提出する権利を持ち、開発者の証明書に同意することを証明します（詳細についてはhttp://developercertificate.org/を参照）。

「–no-signoff」を使用して、「Signed-off-by」ラインを追加しません。

--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」フックをバイパスします。githooks[5]も参照してください。

-s <strategy>
--strategy=<strategy>

指定されたマージストラテジーを使用します。トライする順序で指定するために、複数回指定できます。-sオプションがない場合、代わりにストラテジーの組み込みリストが使用されます（シングルヘッドをマージする場合は「git merge-recursive」、それ以外の場合は「git merge-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

操作を開始する前に一時的なスタッシュエントリを自動的に作成し、操作の終了後に適用します。これはダーティワークツリーで操作を実行できることを意味します。ただし注意して使用してください。マージが成功した後の最後のスタッシュアプリケーションは重要なコンフリクトを引き起こす可能性があります。

--allow-unrelated-histories

デフォルトではgit merge コマンドは共通の祖先を共有しない履歴のマージを拒否します。このオプションは独立して開始した2つのプロジェクトの履歴をマージする時、この安全性を上書きするために使用できます。これは非常にまれなケースであるため、これをデフォルトで有効にする構成変数は存在せず、追加されません。

-m <msg>

マージコミットに使用するコミットメッセージを設定します（マージコミットが作成された場合）。
--logが指定されている場合、マージされるコミットのショートログが指定されたメッセージに追加されます。

「git fmt-merge-msg」コマンドを使用すると、自動化された「git merge」呼び出しに適切なデフォルトを設定できます。自動メッセージにはブランチの説明を含めることができます。

-F <file>
--file=<file>

マージコミットに使用されるコミットメッセージを読み取ります（マージコミットが作成された場合）。

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

--rerere-autoupdate
--no-rerere-autoupdate

可能であれば「rerere」メカニズムが自動コンフリクト解決の結果でインデックスを更新できるようにします。

--overwrite-ignore
--no-overwrite-ignore

マージ結果から無視されたファイルをサイレントに上書きします。 これがデフォルトの動作です。 中止するには--no-overwrite-ignoreを使用します。

--abort

現在のコンフリクト解決プロセスを中止し、マージ前の状態で再構築します。自動スタッシュエントリが存在する場合、それをワークツリーに適用します。

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

「git merge –abort」はMERGE_AUTOSTASH が存在しない限り、MERGE_HEADが存在する場合の「git reset –merge」と同等になります。この場合「git merge –abort」はスタッシュエントリをワークツリーに適用しますが、「git reset—merge」は隠された変更を スタッシュリストに保存します。

--quit

進行中の現在のマージを忘れます。インデックスとワークツリーはそのままにしておきます。MERGE_AUTOSTASH が存在する場合、スタッシュエントリはスタッシュリストに保存されます。

--continue

コンフリクトが原因で「git merge」が停止した後、「git merge –continue」を実行してマージを終了できます（以下の「コンフリクトを解決する方法」セクションを参照）。

<commit>…

ブランチにマージすることをコミットします。通常は他のブランチヘッドとなります。複数のコミットを指定すると、3つ以上のペアレントのマージが作成されます（愛情を込めてオクトパスマージと呼ばれます）。

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

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

マージ前のチェック

外部の変更を適用する前に自分のワークを適切な状態にしてローカルでコミットする必要があります。これによりコンフリクトが発生した場合に作業が中断されることはありません。git-stash[1]も参照してください。ローカルのコミットされていない変更が「gitpull / git merge」の更新が必要なファイルと重複する場合、「gitpull」と「gitmerge」は何もせずに停止します。

マージコミットに無関係な変更が記録されないようにするために、HEADコミットに関連してインデックスに変更が登録されている場合、「gitpull」と「gitmerge」も中止されます。 （使用しているマージストラテジーによっては、このルールに特別な例外が存在する場合がありますが、通常、インデックスはヘッドと一致する必要があります。）

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

ファーストフォワードマージ

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

この動作は--no-ff オプションを使用して抑制することができます。

真のマージ

ファーストフォワードマージ（上記を参照）を除いて、マージされるブランチは両方をペアレントとして持つマージコミットによって統合される必要があります。

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

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

1. HEADポインタは同じままです。
2. MERGE_HEAD 参照は他のブランチヘッドを指すように設定されています。
3. 正常にマージされたパスはインデックスファイルとワークツリーの両方で更新されます。
4. コンフリクトするパスの場合、インデックスファイルは最大3つのバージョンを記録します。ステージ1は共通の祖先からのバージョン、ステージ2はHEADから、ステージ3はMERGE_HEAD から保存します（ステージはgit ls-files -uで検査できます）。ワークツリーファイルには「マージ」プログラムの結果が含まれています。つまり3方向マージは使い慣れたコンフリクトマーカー<<< === >>>となります。
5. その他の変更は行われません。特にマージを開始する前に行ったローカルの変更は同じままであり、それらのインデックスエントリはそのままHEADと一致します。

複雑なコンフリクトが発生したマージのトライを最初からやり直したい場合、git merge --abortを使用してリカバリーできます。

マージタグ

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

たまたまタグ付けされたコミットにつながるワークと統合したい場合、例えばアップストリームリリースポイントと同期する場合、不要なマージコミットを行わないようにすることができます。

このような場合、タグをgit mergeにフィードする前に自身で「unwrap」するか、自分でワークを行っていない場合にのみ--ff-onlyをパスすることができます。

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

コンフリクトの提示方法

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

デフォルトではGitはRCSスイートの「マージ」プログラムで使用されるものと同じスタイルを使用して、次のようにコンフリクトするハンクを表示します。

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed.
<<<<<<< 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」に設定することにより、別のスタイルを使用できます。 「diff3」スタイルでは上記のコンフリクトは次のようになります。

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
|||||||
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でインデックスに追加します。「gitcommit」または「gitmerge –continue」を使用して、ディールを成立させます。後者のコマンドは「git commit」を呼び出す前に、進行中の（中断された）マージがあるかどうかを確認します。

いくつかのツールを使用して、コンフリクトを回避できます。

• 「mergetool」を使用します。git mergetoolを使用して、マージを実行するグラフィカルな「mergetool」を起動します。
• 差分を見ます。git diff はHEADとMERGE_HEAD バージョンの両方からの変更をハイライトする3方向の差分を表示します。
• 各ブランチの違いを確認します。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> 引数を指定することでパスすることができます。

resolve

これは3方向マージアルゴリズムを使用して、2つのヘッド（つまり、現在のブランチとプルした別のブランチ）のみを解決できます。交差するマージのあいまいさを注意深く検出し、一般的に安全で高速であると見なされます。

recursive

これは3方向マージアルゴリズムを使用して2つのヘッドのみを解決できます。3方向マージに使用できる共通の祖先が複数ある場合、共通の祖先のマージされたツリーを作成し、それを3方向マージの参照ツリーとして使用します。これにより、Linux 2.6カーネル開発履歴から取得した実際のマージコミットで実行されたテストによって、ミスマージを引き起こすことなく、マージのコンフリクトが少なくなることが報告されています。さらにこれは名前変更を含むマージを検出して処理できますが、現在、検出されたコピーを利用することはできません。これは1つのブランチをプルまたはマージするときのデフォルトのマージストラテジーです。
「recursive」ストラテジーでは次のオプションを選択できます。

ours

このオプションはコンフリクトするハンクを私たちのバージョンを優先することによってクリーンに自動解決するように強制します。私たちの側とコンフリクトしない他のツリーからの変更はマージ結果に反映されます。バイナリファイルの場合、内容全体が私たちの側から取得されます。
これを他のツリーに何が含まれているかをまったく調べないマージストラテジーと混同しません。それは他のツリーが行ったすべてを破棄し、私たちの履歴にはその中で起こったすべてが含まれていると宣言されています。

theirs

これは「ours」の反対となります。「ours」とは異なり、このマージオプションを混同する「theirs」のマージストラテジーはないことに注意してください。

patience

このオプションを使用すると、「merge-recursive」は重要でない一致するライン（例えば、別個の関数からの中括弧）が原因で発生することがある誤マージを回避するために、時間を使います。マージするブランチが大きく分岐している場合に使用します。git-diff[1]の--patienceも参照してください。

diff-algorithm=[patience|minimal|histogram|myers]

異なる差分アルゴリズムを使用するように「merge-recursive」に指示します。これにより重要でない一致するライン（個別の関数からの中括弧など）が原因で発生するミスマージを回避できます。git-diff[1]の--diff-algorithmも参照してください。

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も参照してください。

• 「their」バージョンがラインに空白の変更のみを導入する場合、「our」バージョンが使用されます。
• 「our」バージョンで空白の変更が導入されているが、「their」バージョンに大幅な変更が含まれている場合、「their」バージョンが使用されます。
• それ以外の場合、マージは通常の方法で進行します。

renormalize

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

no-renormalize

renormalizeオプションを無効にします。これはmerge.renormalize構成変数を上書きします。

no-renames

名前変更の検出をオフにします。これはmerge.renames構成変数を上書きします。git-diff[1]の--no-renamesも参照してください。

find-renames[=<n>]

名前変更検出をオンにし、オプションで類似性のしきい値を設定します。これがデフォルトとなります。これは「merge.renames」構成変数を上書きします。git-diff[1]の--find-renamesも参照してください。

rename-threshold=<n>

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

subtree[=<path>]

このオプションはサブツリーストラテジーのより高度なフォーマットであり、このストラテジーはマージ時に2つのツリーを互いに一致させるためにどのようにシフトする必要があるかを推測します。代わりに指定されたパスにプレフィックスが付けられ（または最初から削除され）、2つのツリーの形状が一致するようになります。

octopus

これにより3つ以上のヘッドがあるケースは解決されますが、手動で解決する必要がある複雑なマージを行うことはできません。 これは主にトピックのブランチヘッドをまとめるために使用することを目的としています。これは複数のブランチをプルまたはマージする場合のデフォルトのマージストラテジーです。

ours

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

subtree

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

3方向マージ（デフォルト、「recursive」を含む）を使用する戦略では両方のブランチで変更が行われますが、後でブランチの1つで元に戻された場合、その変更はマージされた結果に表示されます。これに混乱する人もいます。これは個々のコミットではなく、ヘッドとマージベースのみがマージの実行時に考慮されるために発生します。したがって、マージアルゴリズムは元に戻された変更をまったく変更なしと見なし、代わりに変更されたバージョンに置き換えます。

構成

merge.conflictStyle

マージ時にコンフリクトするハンクがワークツリーファイルに書き出されるスタイルを指定します。 デフォルトは「マージ」で<<<<<<<コンフリクトマーカー、一方の側で行われた変更、=======マーカー、もう一方の側で行われた変更、そして>>>>>>>を表示します。別のスタイルである「diff3」は||||||| を追加し、=======マーカーの前のオリジナルテキストを追加します。

merge.defaultToUpstream

commit引数を指定せずにmergeが呼び出された場合、リモートトラッキングブランチに格納されている最後に観測された値を使用し、現在のブランチ用に構成されたアップストリームブランチをマージします。branch.<current branch>.remote によって名前が付けられたリモートのブランチに名前を付けるbranch.<current branch>.merge の値が参照され、remote.<remote>.fetch を介して対応する「remote-」にマップされます。追跡ブランチ、およびこれらのトラッキングブランチのヒントがマージされます。

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

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

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

merge.renameLimit

マージ中に名前変更の検出を実行するときに考慮するファイルの数です。指定しない場合、デフォルトで「diff.renameLimit」の値になります。名前変更の検出がオフになっている場合、この設定は効果がありません。

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

True by default. マージの最後に「ORIG_HEAD」とマージ結果の間の差分を出力するかどうかです。 デフォルトでは「True」となっています。

merge.autoStash

「true」に設定すると、操作を開始する前に一時的なスタッシュエントリを自動的に作成し、操作の終了後に適用します。これはダーティワークツリーでマージを実行できることを意味します。ただし、注意して使用してください。マージが成功した後の最後のスタッシュアプリケーションは重要なコンフリクトを引き起こす可能性があります。このオプションは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
• 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]を参照してください。

branch.<name>.mergeOptions

ブランチ<name>にマージするためのデフォルトオプションを設定します。構文とサポートされているオプションは「gitmerge」のものと同じですが、空白文字を含むオプション値は現在サポートされていません。

参照

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

git[1]パッケージソフトの一部

git公式ドキュメント

merge