SYNOPSIS

git merge [-n] [--stat] [--compact-summary] [--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

Then git merge topic will replay the changes made on the topic branch since it diverged from master (i.e., E) until its current commit (C) on top of master, and record the result in a new commit along with the names of the two parent commits and a log message from the user describing the changes. Before the operation, ORIG_HEAD is set to the tip of the current branch (G).

          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
 Running git merge with non-trivial uncommitted changes is discouraged: while possible, it may leave you in a state that is hard to back out of in the case of a conflict.

OPTIONS

--commit
--no-commit

Perform the merge and commit the result. This option can be used to override --no-commit.

With --no-commit perform the merge and stop just before creating a merge commit, to give the user a chance to inspect and further tweak the merge result before committing.

Note that fast-forward updates do not create a merge commit and therefore there is no way to stop those merges with --no-commit. Thus, if you want to ensure your branch is not changed or updated by the merge command, use --no-ff with --no-commit.

--edit
-e
--no-edit

機械的なマージが成功する前にエディターを呼び出して、 自動生成されたマージ・メッセージをさらに編集し、 ユーザーがマージについて説明して正当化できるようにします。 --no-edit オプションを使用して、 自動生成されたメッセージを受け入れることができます(これは一般的には推奨されていません)。 --edit(または -e) オプションは、あなたがコマンドラインから -m オプションで与えた下書きメッセージをエディタで編集したい場合にも便利です。

古いスクリプトは、 ユーザーにマージ・ログ・メッセージの編集を許さないという過去の振る舞いに依存している可能性があります。 そのような場合に git merge を実行すると、 エディターを拝むハメになります。 このようなスクリプトを簡単に最新の振る舞いに合わせるために、 環境変数 GIT_MERGE_AUTOEDIT をスクリプトの先頭で no に設定できます。

--cleanup=<mode>

This option determines how the merge message will be cleaned up before committing. See git-commit(1) for more details. In addition, if the <mode> is given a value of scissors, scissors will be appended to MERGE_MSG before being passed on to the commit machinery in the case of a merge conflict.

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

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

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

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

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

-S[<key-id>]
--gpg-sign[=<key-id>]
--no-gpg-sign

GPG-sign the resulting merge commit. The <key-id> argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space. --no-gpg-sign is useful to countermand both commit.gpgSign configuration variable, and earlier --gpg-sign.

--log[=<n>]
--no-log

In addition to branch names, populate the log message with one-line descriptions from at most <n> actual commits that are being merged. See also git-fmt-merge-msg(1).

With --no-log do not list one-line descriptions from the actual commits being merged.

--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によっても制御されます。

With -n or --no-stat do not show a diffstat at the end of the merge.

--compact-summary

Show a compact-summary at the end of the merge.

--squash
--no-squash

(マージ情報を除く)実際のマージが発生したかのように作業ツリーとインデックスの状態を生成しますが、 実際にコミットしたり、 HEAD を移動したり、 $GIT_DIR/MERGE_HEAD を記録したりしません(つまり、 次の git commit コマンドでマージ・コミットが作成されます)。 これにより、 あなたは現在のブランチの上に単一のコミットを作成できます。その効果は、別のブランチ(または octopus の場合は、 複数のブランチ)をマージするのと同じです。

With --no-squash perform the merge and commit the result. This option can be used to override --squash.

With --squash, --commit is not allowed, and will fail.

--verify
--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

Synonyms to --stat and --no-stat; these are deprecated and will be removed in the future.

-q
--quiet

Operate quietly. Implies --no-progress.

-v
--verbose

にぎやかにします。

--progress
--no-progress

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

--autostash
--no-autostash

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

--allow-unrelated-histories

By default, git merge command refuses to merge histories that do not share a common ancestor. This option can be used to override this safety when merging histories of two projects that started their lives independently. As that is a very rare occasion, no configuration variable to enable this by default exists or will be added.

-m <msg>

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

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

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

--into-name <branch>

Prepare the default merge message as if merging to the branch <branch>, instead of the name of the real branch to which the merge is made.

-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)します。

To avoid recording unrelated changes in the merge commit, git pull and git merge will also abort if there are any changes registered in the index relative to the HEAD commit. (Special narrow exceptions to this rule may exist depending on which merge strategy is in use, but generally, the index must match 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. For conflicting paths, the index file records up to three versions: stage 1 stores the version from the common ancestor, stage 2 from HEAD, and stage 3 from MERGE_HEAD (you can inspect the stages with git ls-files -u). The working tree files contain the result of the merge operation; i.e. 3-way merge results with familiar conflict markers <<< === >>>.

  5. A ref named AUTO_MERGE is written, pointing to a tree corresponding to the current content of the working tree (including conflict markers for textual conflicts). Note that this ref is only written when the ort merge strategy is used (the default).

  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.

The area where a pair of conflicting changes happened is marked with markers <<<<<<<, =======, and >>>>>>>. The part before the ======= is typically your side, and the part afterwards is typically their side.

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

An alternative style can be used by setting the merge.conflictStyle configuration variable to either diff3 or zdiff3. In diff3 style, the above conflict may look like this:

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.

while in zdiff3 style, it may look like this:

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.

In addition to the <<<<<<<, =======, and >>>>>>> markers, it uses another ||||||| marker that is followed by the original text. You can tell that the original just stated a fact, and your side simply gave in to that statement and gave up, while the other side tried to have a more positive attitude. You can sometimes come up with a better resolution by viewing the original.

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」の代わりとして作成されたという事実に由来しています。

In the case where the path is a submodule, if the submodule commit used on one side of the merge is a descendant of the submodule commit used on the other side of the merge, Git attempts to fast-forward to the descendant. Otherwise, Git will treat this case as a conflict, suggesting as a resolution a submodule commit that is descendant of the conflicting ones, if one exists.

The ort strategy can take the following options:

ours

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

This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring our history contains all that happened in it.

theirs

This is the opposite of ours; note that, unlike ours, there is no theirs merge strategy to confuse this merge option with.

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

This runs a virtual check-out and check-in of all three stages of any file which needs a three-way merge. This option is meant to be used when merging branches with different clean filters or end-of-line normalization rules. See "Merging branches with differing checkin/checkout attributes" in gitattributes(5) for details.

no-renormalize

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

find-renames[=<n>]

Turn on rename detection, optionally setting the similarity threshold. This is the default. This overrides the merge.renames configuration variable. See also git-diff(1) --find-renames.

rename-threshold=<n>

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

no-renames

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

histogram

Deprecated synonym for diff-algorithm=histogram.

patience

diff-algorithm=patience の非推奨の同義語。

diff-algorithm=(histogram|minimal|myers|patience)

Use a different diff algorithm while merging, which can help avoid mismerges that occur due to unimportant matching lines (such as braces from distinct functions). See also git-diff(1) --diff-algorithm. Note that ort defaults to diff-algorithm=histogram, while regular diffs currently default to the diff.algorithm config setting.

subtree[=<path>]

このオプションは「subtree」戦略をさらに発展させたもので、2つの木をマージする際に、どのようにずらせば互いにマッチするかを推測するものである。その代わり、指定されたパスは、2つの木の形が一致するように前置される(または、最初から取り除かれる)。

recursive

This is now a synonym for ort. It was an alternative implementation until v2.49.0, but was redirected to mean ort in v2.50.0. The previous recursive strategy was the default strategy for resolving two heads from Git v0.99.9k until v2.33.0.

resolve

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

octopus

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

ours

This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the -Xours option to the ort merge strategy.

subtree

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

With the strategies that use 3-way merge (including the default, ort), if a change is made on both branches, but later reverted on one of the branches, that change will be present in the merged result; some people find this behavior confusing. It occurs because only the heads and the merge base are considered when performing a merge, not the individual commits. The merge algorithm therefore considers the reverted change as no change at all, and substitutes the changed version instead.

CONFIGURATION

branch.<name>.mergeOptions

Sets default options for merging into branch <name>. The syntax and supported options are the same as those of git merge, but option values containing whitespace characters are currently not supported.

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

merge.conflictStyle

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

merge.defaultToUpstream

コミット引数なしで merge が呼び出された場合は、 リモート追跡ブランチに格納されている最後に観測された値を使用して、 現在のブランチ用に構成された上流ブランチをマージします。 branch.<current-branch>.remote によって指定されたリモートのブランチに名前を付ける branch.<current-branch>.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 がディレクトリ名の変更を検出するかどうかを指定します。 これにより、 履歴の一方の側でディレクトリ名が変更されたときに、 もう一方の側でそのディレクトリに追加された新しいファイルがマージ時にどのように扱われるかが影響を受けます。 指定可能な値は以下の通りです:

false

ディレクトリ名の変更検出が無効になります。 この場合、 そのような新しいファイルは古いディレクトリのまま残されます。

true

ディレクトリ名の変更検出が有効になります。 この場合、 そのような新しいファイルは新しいディレクトリに移動されます。

conflict

そのようなパスについて競合が報告されます。

merge.renames が false の場合、 merge.directoryRenames は無視され、 false として扱われます。デフォルトは conflict です。

merge.renormalize

リポジトリー内のファイルの正規の形式(canonical representation)が時間とともに変化したことを Git に伝える設定です(例: 古いコミットではテキスト・ファイルが CRLF 行末を使用していたが、 最近のコミットでは LF 行末を使用しているとか)。 このようなリポジトリーでは、3方向のコンテンツ・マージが必要なファイルごとに、 Git はマージを実行する前にコミットに記録されたデータを正規の形式に変換できます。 これにより、 不必要な競合を減らすことが可能です。 詳細については、 gitattributes(5) の「Merging branches with differing checkin/checkout attributes」（チェックイン/チェックアウト属性が異なるブランチのマージ）セクションを参照してください。

merge.stat

マージの終了時に、 ORIG_HEAD とマージ結果(merge result)の間に何か表示するものがあれば、 表示します。 指定可能な値は以下の通りです:

false

何も表示しません。

true

git diff --diffstat --summary ORIG_HEAD の出力を表示します。

compact

git diff --compact-summary ORIG_HEAD の出力を表示します。

認識されない値(たとえば、 将来の Git バージョンで値が追加された等)が指定された場合、 エラーではなく true として扱われます。 デフォルトは true です。

merge.autoStash

true に設定すると、 操作開始前に自動的に一時的なスタッシュ・エントリを作成し、 操作終了後にそれを適用(apply)します。 これにより、 作業ツリーがダーティなの状態でもマージを実行できます。 ただし注意して使用してください：成功したマージ後の最終的なスタッシュの適用(applY)で、 深刻な競合が発生する可能性があります。 このオプションは git-merge(1) の --no-autostash および --autostash オプションで上書きできます。デフォルトは false です。

merge.tool

git-mergetool(1) で使用するマージ・ツールを制御します。 下記リストに示す値が有効な組み込み値です。 それ以外の値はカスタム・マージ・ツールとして扱われ、 対応する mergetool.<tool>.cmd 変数が定義されている必要があります(訳注: 原文にもリストの掲載無し。 うーん分からん)。

merge.guitool

git-mergetool(1) で -g や --gui フラグが指定されたときに使用するマージ・ツールを制御します。 以下リストに示す値が有効な組み込み値です。 それ以外の値はカスタム・マージツールとして扱われ、 対応する 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