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 によって使用され、 そしてまた、 手動で、 あるブランチから別のブランチへの変更をマージするためにも使用できます。

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

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

ここで git merge topic を実行すると、 topic ブランチが master から分岐した時点(ここでは E)以降に topic ブランチで行われた変更を再生(replay)し、 現在のコミット(C)までを master 上に適用します。 そして、 その結果を新しいコミットとして記録し、 一緒に、 2つの親コミットの名前と、 ユーザーが変更を説明するログ・メッセージを保存します。 ORIG_HEAD は、 この操作の前に、 現在のブランチの先端(C)に設定されます。

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

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

git merge --abort はマージ処理を中止し、 マージ前の状態を再構築しようとします。 ただし、マージの開始時にコミットされていない変更があった場合(特に、マージの開始後にそれらの変更がさらに変更された場合)、 git merge --abort は、元の(マージ前の)変更を再構築できない場合があります。 つまり以下の事が言えます:

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

OPTIONS

--commit
--no-commit

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

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

注意: 早送り(fast-forward)更新はマージコミットを作成しないため、 --no-commit を使用してこれらのマージを停止する方法はないことに注意してください。 したがって、mergeコマンドによってブランチが変更または更新されないようにする場合は、 --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 を指定した場合、 マージの競合が発生した時、 コミット機構に渡される前に、 切り取り線(scissors)が MERGE_MSG に追加されます。

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

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

--ff を使用すると、可能であれば、マージを早送り(fast-forward)(マージされたブランチに一致するようにブランチポインタを更新するだけです。マージコミットは作成しません)として解決します。 不可能な場合(マージされた履歴が現在の履歴の子孫ではない場合)は、マージコミットを作成します。

--no-ff を使用すると、マージが早送り(fast-forward)として解決できる場合でも、すべての場合にマージコミットを作成します。

--ff-only を使用して、可能な場合はマージを早送り(fast-forward)として解決します。不可能な場合は、マージを拒否し、ゼロ以外のステータスで終了します。

-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」トレーラーを追加します。 signoff(訳注: 一般には手紙の(末尾の)署名)の意味は、 コミットしているプロジェクトによって異なります。 たとえば、 コミッターがプロジェクトのライセンスに基づいて作品を提出する権利を持っていることを証明したり、開発者の原産地証明書などの寄稿者の代表に同意したりする場合があります(LinuxカーネルおよびGitプロジェクトで使用されるものについては、 https://developercertificate.org を参照してください)。 プロジェクトでsignoffがどのように使用されるかを理解するには、 貢献しているプロジェクトのドキュメントまたはリーダーシップ(leadership)を参照してください。

コマンドラインで --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 コマンドでマージ・コミットが作成されます)。 これにより、 あなたは現在のブランチの上に単一のコミットを作成できます。その効果は、別のブランチ(または octopus の場合は、 複数のブランチ)をマージするのと同じです。

--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を持つキーで署名されていることを確認します。デフォルトの信頼モデルでは、これは署名キーが信頼できるキーによって署名されていることを意味します。サイド・ブランチの先端コミットが有効なキーで署名されていない場合、マージは中止(abort)されます。

--summary
--no-summary

--stat および --no-stat の同義語。 これらは非推奨であり、将来削除される予定です。

-q
--quiet

静かに実行します。 --no-progress の指定を含んでいます。

-v
--verbose

にぎやかにします。

--progress
--no-progress

進行状況を明示的に オン/オフ します。 どちらも指定されていない場合、 標準エラーが端末に接続されていれば進行状況が表示されます。 注意: すべてのマージ戦略が進捗レポートをサポートしているわけではないことに注意してください。

--autostash
--no-autostash

操作を開始する前に一時的なスタッシュ・エントリを自動的に作成し、 それを ref MERGE_AUTOSTASH に記録し、 操作の終了後に適用(apply)します。 これは、 ダーティ・ワークツリーで操作を実行できることを意味します。 ただし、 注意して使用してください: マージの成功後に最後のスタッシュを適用すると深刻な競合を引き起こす可能性があります。

--allow-unrelated-histories

デフォルトでは、 git merge コマンドは、共通の祖先を共有しない履歴のマージを拒否します。 このオプションは、独立して産まれた2つのプロジェクトの履歴をマージするときに、このセーフティを無効にするために使用できます。 これは非常にまれなケースであるため、これをデフォルトで有効にする構成変数は存在せず、今後も追加されないでしょう。

-m <msg>

マージコミットに使用するコミットメッセージを設定します(マージコミットが作成された場合)。

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

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

--into-name <branch>

マージ先の実際のブランチの名前ではなく、ブランチ <branch> にマージするかのように、デフォルトのマージ・メッセージを準備します。

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

(マージ・コミットが作成される場合に備えて)マージ・コミットに使用するコミット・メッセージを読み取ります。

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

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

rerere メカニズムが現在の競合で記録された解決を再利用して作業ツリー内のファイルを更新した後、解決の結果でインデックスも更新できるようにします。 --no-rerere-autoupdate は、別の git add で結果をインデックスにコミットする前に、「rerere」が行ったことを再確認し、潜在的な間違いマージ(mismerges)を捉える良い方法です。

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

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

--abort

現在の競合解決プロセスを中止(abort)し、マージ前の状態を再構築してみてください。 自動スタッシュエントリが存在する場合は、それをワークツリーに適用します。

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

git merge --abort は、 MERGE_HEAD がある場合は git reset --merge と同じです。ただし MERGE_AUTOSTASH もある場合は git merge --abort はスタッシュ・エントリをワーク・ツリーに適用しますが、 git reset --merge は スタッシュ・リストにスタッシュした変更を保持したままにします。

--quit

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

--continue

競合が原因で git merge が停止(stop)した後で、 git merge --continue を実行してマージを終了できます(下記「HOW TO RESOLVE CONFLICTS」セクション参照)。

<commit>…

通常、 他のブランチのヘッドであるコミットを、 私たちのブランチにマージします。 2つ以上のコミットを指定すると、 3つ以上の親を持つマージが作成されます(Octopusマージという愛称で親しまれています)。

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

FETCH_HEAD` が指定された場合(他のコミットは指定しない場合)、直前の git fetch によるマージによって .git/FETCH_HEAD ファイルに記録されたブランチは、現在のブランチにマージされます。

PRE-MERGE CHECKS

外部の変更を適用する前に、自分の作業を良好な状態にしてローカルでコミットしとく必要があります。これにより、競合が発生した場合に作業が中断されることはなくなります。 git-stash(1) も参照してください。 git pull/git merge は、ローカルのコミットされていない変更が git pull/git merge の更新が必要なファイルと重複する場合、何もせずに停止(stop)します。

マージ・コミットに無関係な変更が記録されないようにするために、 HEAD コミットに関連する変更がインデックスに登録されている場合、 git pull と git merge も中止(abort)されます。 (使用されているマージ戦略によっては、このルールに対する特別な狭い例外が存在する場合がありますが、通常、インデックスはHEADと一致する必要があります。)

すべての名前付きコミットがすでに HEAD の祖先である場合、git merge は "Already up to date." (既に最新です)というメッセージで早期に終了(exit)します。

FAST-FORWARD MERGE

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

この振る舞いは、--no-ff オプションで抑制できます。

TRUE MERGE

早送りマージ(fast-forward merge)(上記参照)を除いて、マージされるブランチは、両方を親として持つマージコミットによって結合する必要があります。

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

変更を調停する方法が明確でない場合、以下のようになります:

  1. HEAD ポインタは同一のままです。

  2. MERGE_HEAD ref は、他方のブランチヘッド(the other branch head)を指すように設定されています。

  3. 正常にマージされたパスは、インデックスファイルとあなたの作業ツリーの両方で更新されます。

  4. 競合するパスの場合、インデックスファイルには最大3つのバージョンが記録されます: ステージ1は、共通の祖先からのバージョンを格納し、ステージ2 は HEAD からのバージョン、 ステージ3 は MERGE_HEAD からのバージョンです(あなたは git ls-files -u でステージを検査できます)。 作業ツリーファイルにはマージ操作の結果が含まれています。 つまり、おなじみの競合マーカー <<< === >>> を使用した3方向マージの結果です。

  5. AUTO_MERGE という名前の ref が書き込まれ、 作業ツリーの現在の内容に対応するツリーを指します(テキストの競合のための競合マーカーを含む)。 この ref は、 ort マージ戦略が使用される(これがデフォルトです)場合にのみ書き込まれることに注意してください。

  6. その他の変更は行われません。 特に、マージを開始する前に行ったローカルの変更は同じままであり、それらのインデックスエントリはそのまま、つまり「HEAD」と一致します。

試しにマージした結果、複雑な競合が発生してしまったのでやり直したいという場合は、 git merge --abort で回復(recover)することができます。

MERGING TAG

注釈付きの(可能ならば署名された)タグをマージする場合、早送りマージが可能であっても、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

HOW CONFLICTS ARE PRESENTED(競合の提示方法)

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

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

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.

競合する変更のペアが発生した領域は、マーカー <<<<<<< 、 ======= 、 >>>>>>> でマークされます。 ======= の前の部分は通常あなた側(your side)であり、後の部分は通常彼ら側(their side)です。

デフォルトの形式では、競合している部分でオリジナルが何を言っているのかは分かりません。 自分側の何行が削除され、バービー人形の発言に置き換えられているのかは分かりません。 唯一わかるのは、あなた側(your side)は大変だから買い物に行きたいと言いたいのに、相手側(the other size)は簡単だと主張したいということです。

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.

<<<<<<< 、 ======= 、 >>>>>>> マーカーに加えて、||||||| マーカーにオリジナルのテキストが続きます。 オリジナルは事実を述べただけであり、あなたの側(your side)は単にその声明に屈して諦めたのに対し、他の側(the oter side)はより前向きな態度をとろうとしたことがわかります。 オリジナルを表示することで、より良い解決策を思い付くことができる場合があります。

HOW TO RESOLVE CONFLICTS

競合を目にした後、あなたは以下の2つのことができます:

  • マージしないことを決定します。 必要なクリーンアップは、インデックスファイルを HEAD コミットにリセットして (2) をリバースし、 (2) と (3) によって行われた作業ツリーの変更をクリーンアップすることだけです。 これには git merge --abort を使用できます。

  • 競合を解決します。 Gitは、作業ツリーの競合をマークします。 ファイルを編集して形にし、git add してインデックスに追加します。 git commit または git merge --continue を使用して、取引を成立させます。 後者のコマンドは、 git commit を呼び出す前に、進行中の(中断(interrupted)された)マージがあるかどうかをチェックします。

あなたはいくつかの道具を使用して、競合を解決できます:

  • mergetool を使用します。 git mergetool を実行すると、 グラフィカルなマージ・ツールが起動し、 あなたと一緒にマージ作業を進めてくれます。

  • diffを見てください。 git diff は3方向の差分を表示し、 HEAD バージョンと MERGE_HEAD バージョンの両方からの変更を強調表示します。 git diff AUTO_MERGE では、 あなたがテキストの競合を解決するためにこれまでに行った変更が表示されます。

  • 各ブランチからのdiffを見てください。 git log --merge -p <path> は、最初に HEAD バージョンの差分を表示し、次に MERGE_HEAD バージョンを表示します。

  • オリジナルを見てください。 git show :1:filename は共通の祖先を示し、 git show :2:filename は HEAD バージョンを示し、 git show :3:filename は MERGE_HEAD バージョンを示します。

EXAMPLES

  • 現在のブランチにブランチ fixes と enhancements をマージし、octopusマージします: 

    $ git merge fixes enhancements

  • ours マージ戦略を使用して、ブランチ obsolete を現在のブランチにマージします: 

    $ git merge -s ours obsolete

  • ブランチ maint を現在のブランチにマージしますが、新しいコミットを自動的に行わないでください: 

    $ git merge --no-commit maint

    これは、マージにさらに変更を加えたい場合、または独自のマージコミットメッセージを作成したい場合に使用できます。

    大幅な変更をマージコミットに忍び込ませるために、このオプションを悪用することは控えてください。 bumping release(微修正)/version name(バージョン名変更) のような小さな修正は許容されます。

MERGE STRATEGIES

マージ機構(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

このオプションは、「our」バージョンを優先することにより、競合するハンクをクリーンに自動解決するように強制します。 our側と競合しない他のツリーからの変更は、マージ結果に反映されます。 バイナリファイルの場合、内容全体がour側から取得されます。

これを「ours」マージ戦略と混同しないでください。「ours」マージ戦略では、他のツリーに何が含まれているのかさえまったく調べません。それは他のツリーが行ったすべてを破棄し、「our」履歴にはその中で起こったすべてが含まれていると宣言します。

theirs

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

ignore-space-change
ignore-all-space
ignore-space-at-eol
ignore-cr-at-eol

指示されたタイプの空白(whitespace)の変更を含む行を、3方向マージのために変更されていないものとして扱います。行に対する、他の変更と空白(whitespace)の変更との混合は、無視されません。 git-diff(1) の -b と -w と --ignore-space-at-eol と --ignore-cr-at-eol も参照してください。

  • 「their」バージョンが行に空白の変更のみを導入する場合、「our」バージョンが使用されます。

  • 「our」バージョンで空白の変更が導入されたが、「their」バージョンに大幅な変更が含まれている場合は、「their」バージョンが使用されます。

  • それ以外の場合、マージは通常の方法で進行します。

renormalize

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

no-renormalize

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

find-renames[=<n>]

名前変更(rename)の検出をオンにし、オプションで類似性のしきい値(similarity threshold)を設定します。これがデフォルトです。 これは、 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

名前変更(rename)の検出をオフにします。 これは、merge.renames 構成変数をオーバーライドします。 git-diff(1) の --no-renames も参照してください。

resolve

これは、3方向マージアルゴリズムを使用して、2つのヘッド（つまり、現在のブランチとプルした別のブランチ）のみを解決できます。 交差マージ(criss-cross merge)のあいまいさを注意深く検出しようとします。 名前の変更は処理しません。

octopus

これにより、3つ以上のヘッドを持つケースが解決されますが、手動解決が必要な複雑なマージの実行は拒否されます。これは主に、トピックの分岐ヘッドを纏めるために使用されることを意図しています。これは、複数のブランチをプルまたはマージする場合のデフォルトのマージ戦略です。

ours

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

subtree

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

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

CONFIGURATION

branch.<name>.mergeOptions

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

このセクションのこの行より上にあるものはすべて、 git-config(1) ドキュメントには含まれていません。 以下の内容に関しては、git-config(1) ドキュメント にあるものと同一です。

merge.conflictStyle

マージ時に競合するハンクが作業ツリーファイルに書き出されるスタイルを指定します。 デフォルトは merge`です。 これは、 `<<<<<<< 競合マーカー、 一方の側で行われた変更、 ======= マーカー、 もう一方の側で行われた変更、 >>>>>>> マーカー、 というスタイルです。 別のスタイル「diff3」は、 ||||||| マーカーと元のテキストを ======= マーカーの前に追加します。 merge スタイルは、 元のテキストの除外と、 行のサブセットが両側で一致する場合に競合領域から引き抜かれるという、 両方の理由により、 diff3 よりも競合領域が小さくなる傾向があります。 もう 1 つの代替スタイル zdiff3 は diff3 に似ていますが、 両側で一致する行が競合領域の開始または最後近くに現れる場合、競合領域から削除します。

merge.defaultToUpstream

コミット引数なしでmergeが呼び出された場合は、リモート追跡ブランチに格納されている最後に観測された値を使用して、現在のブランチ用に構成されたアップストリームブランチをマージします。 branch.<currentbranch>.remote によって指定されたリモートのブランチに名前を付ける branch.<currentbranch>.merge の値が参照され、次に、それらは remote.<remote>.fetch を介して対応するリモート追跡ブランチにマッピングされ、そして、これらの追跡ブランチの先端がマージされます。 デフォルトはtrueです。

merge.ff

デフォルトでは、Gitは、現在のコミットの子孫であるコミットをマージするときに、追加のマージコミットを作成しません。 代わりに、現在のブランチの先端が早送り(fast-forward)されます。 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

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

空の値を持つ要素を使用して、以前の構成エントリから蓄積されたグロブのリストをクリアできます。 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) の「Merging branches with differing checkin/checkout attributes」(チェックイン/チェックアウト属性が異なるブランチのマージ)のセクションを参照してください。

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

Use Araxis Merge (requires a graphical session)

bc

Use Beyond Compare (requires a graphical session)

bc3

Use Beyond Compare (requires a graphical session)

bc4

Use Beyond Compare (requires a graphical session)

codecompare

Use Code Compare (requires a graphical session)

deltawalker

Use DeltaWalker (requires a graphical session)

diffmerge

Use DiffMerge (requires a graphical session)

diffuse

Use Diffuse (requires a graphical session)

ecmerge

Use ECMerge (requires a graphical session)

emerge

Use Emacs' Emerge

examdiff

Use ExamDiff Pro (requires a graphical session)

guiffy

Use Guiffy’s Diff Tool (requires a graphical session)

gvimdiff

Use gVim (requires a graphical session) with a custom layout (see git help mergetool's BACKEND SPECIFIC HINTS section)

gvimdiff1

Use gVim (requires a graphical session) with a 2 panes layout (LOCAL and REMOTE)

gvimdiff2

Use gVim (requires a graphical session) with a 3 panes layout (LOCAL, MERGED and REMOTE)

gvimdiff3

Use gVim (requires a graphical session) where only the MERGED file is shown

kdiff3

Use KDiff3 (requires a graphical session)

meld

Use Meld (requires a graphical session) with optional auto merge (see git help mergetool's CONFIGURATION section)

nvimdiff

Use Neovim with a custom layout (see git help mergetool's BACKEND SPECIFIC HINTS section)

nvimdiff1

Use Neovim with a 2 panes layout (LOCAL and REMOTE)

nvimdiff2

Use Neovim with a 3 panes layout (LOCAL, MERGED and REMOTE)

nvimdiff3

Use Neovim where only the MERGED file is shown

opendiff

Use FileMerge (requires a graphical session)

p4merge

Use HelixCore P4Merge (requires a graphical session)

smerge

Use Sublime Merge (requires a graphical session)

tkdiff

Use TkDiff (requires a graphical session)

tortoisemerge

Use TortoiseMerge (requires a graphical session)

vimdiff

Use Vim with a custom layout (see git help mergetool's BACKEND SPECIFIC HINTS section)

vimdiff1

Use Vim with a 2 panes layout (LOCAL and REMOTE)

vimdiff2

Use Vim with a 3 panes layout (LOCAL, MERGED and REMOTE)

vimdiff3

Use Vim where only the MERGED file is shown

vscode

Use Visual Studio Code (requires a graphical session)

winmerge

Use WinMerge (requires a graphical session)

xxdiff

Use xxdiff (requires a graphical session)

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

SEE ALSO

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

Part of the git(1) suite