Git

git-merge は 2.49.0 で最終更新

名前

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

説明

指定されたコミット (現在のブランチから履歴が分岐した時点以降) からの変更を現在のブランチに組み込みます。このコマンドは `git pull` によって他のリポジトリからの変更を組み込むために使用され、手動で1つのブランチから別のブランチへ変更をマージするために使用することもできます。

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

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

すると、`git merge topic` は、`topic` ブランチが `master` から分岐した時点 (`E` と仮定) から現在のコミット (`C`) までの `topic` ブランチでの変更を `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` を実行することは推奨されません。可能ではありますが、競合が発生した場合に元に戻すのが難しい状態になる可能性があります。

オプション

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

--no-commit を指定すると、マージを実行し、マージコミットを作成する直前で停止します。これにより、ユーザーはコミットする前にマージ結果を検査し、さらに調整する機会が得られます。

ファストフォワード更新はマージコミットを作成しないため、--no-commit でこれらのマージを停止する方法はありません。したがって、マージコマンドによってブランチが変更または更新されないようにしたい場合は、--no-commit と共に --no-ff を使用してください。
--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` が仮定されます。

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

--no-ff を使用すると、マージがファストフォワードとして解決できる場合でも、すべての場合でマージコミットを作成します。

--ff-only を使用すると、可能な場合はマージをファストフォワードとして解決します。不可能な場合は、マージを拒否し、0以外のステータスで終了します。
-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` トレーラーを追加します。サインオフの意味は、コミット先のプロジェクトによって異なります。例えば、コミッターがプロジェクトのライセンスの下で作業を提出する権利があることを証明したり、Developer Certificate of Origin のような貢献者表明に同意することを示す場合があります。（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` コマンドでマージコミットを作成させるため)。これにより、現在のブランチの上に、別のブランチをマージするのと同じ効果を持つ単一のコミットを作成できます (または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: マージされるサイドブランチの先端コミットが有効なキーで署名されていること、つまりデフォルトの信頼モデルにおいて、署名キーが信頼されたキーによって署名されていることを検証します。サイドブランチの先端コミットが有効なキーで署名されていない場合、マージは中止されます。
--summary
--no-summary: --stat および --no-stat の同義語です。これらは非推奨であり、将来削除される予定です。
-q
--quiet: 静かに動作します。--no-progress を含みます。
-v
--verbose: 詳細な出力を表示します。
--progress
--no-progress: 進行状況の表示を明示的にオン/オフします。どちらも指定されていない場合、標準エラーがターミナルに接続されていれば進行状況が表示されます。すべてのマージ戦略が進行状況報告をサポートしているわけではないことに注意してください。
--autostash
--no-autostash: 操作開始前に一時的なスタッシュエントリーを自動的に作成し、`MERGE_AUTOSTASH` リファレンスに記録し、操作終了後にそれを適用します。これは、ダーティな作業ツリー上で操作を実行できることを意味します。ただし、注意して使用してください。成功したマージ後の最終的なスタッシュ適用は、無視できない競合を引き起こす可能性があります。
--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` は、`rerere` が行ったことを再確認し、潜在的な誤ったマージを検出する良い方法です。これは、別途 `git add` で結果をインデックスにコミットする前に行われます。
--overwrite-ignore
--no-overwrite-ignore: マージ結果から無視されたファイルを黙って上書きします。これがデフォルトの動作です。中止するには `--no-overwrite-ignore` を使用します。
--abort: 現在の競合解決プロセスを中止し、マージ前の状態を再構築しようとします。autostash エントリが存在する場合、それを作業ツリーに適用します。

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

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

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

`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` は "Already up to date." (すでに最新です) というメッセージを表示して早期に終了します。

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

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

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

真のマージ

ファストフォワードマージ (上記参照) を除いて、マージされるブランチは、両方を親とするマージコミットによって結合される必要があります。

マージされるすべてのブランチからの変更を調和させたマージ済みのバージョンがコミットされ、`HEAD`、インデックス、および作業ツリーがそれに更新されます。作業ツリーに変更があっても、それらが重なっていない限り変更を維持することが可能です。更新はそれらを保持します。

変更をどのように調整すべきか明らかでない場合、以下が発生します。

`HEAD` ポインタは同じままです。
`MERGE_HEAD` リファレンスは、もう一方のブランチヘッドを指すように設定されます。
きれいにマージされたパスは、インデックスファイルと作業ツリーの両方で更新されます。
競合するパスについては、インデックスファイルが最大3つのバージョンを記録します。ステージ1には共通の祖先からのバージョン、ステージ2には `HEAD` からのバージョン、ステージ3には `MERGE_HEAD` からのバージョンが格納されます (`git ls-files -u` でステージを検査できます)。作業ツリーファイルにはマージ操作の結果が含まれます。つまり、おなじみの競合マーカー `<<<` `===` `>>>` を伴う3ウェイマージの結果です。
`AUTO_MERGE` という名前のリファレンスが書き込まれ、作業ツリーの現在の内容 (テキスト競合の競合マーカーを含む) に対応するツリーを指します。このリファレンスは、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.

競合する変更のペアが発生した領域は、`<<<<<<<`、`=======`、および `>>>>>>>` のマーカーでマークされます。`=======` の前の部分は通常あなた (your side) の変更で、その後の部分は通常相手 (their side) の変更です。

デフォルトのフォーマットでは、競合領域で元の内容がどうであったかは表示されません。あなたの側で何行が削除され、Barbie のコメントに置き換えられたかを判断することはできません。わかるのは、あなたの側が「難しい」と言い、買い物に行きたいと思っているのに対し、相手側は「簡単だ」と主張したいということです。

`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` は、`HEAD` と `MERGE_HEAD` の両方のバージョンからの変更を強調表示する3ウェイ差分を表示します。`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` ブランチをマージし、Octopus マージを作成する
```
$ git merge fixes enhancements
```
`obsolete` ブランチを `ours` マージ戦略を使用して現在のブランチにマージする
```
$ git merge -s ours obsolete
```
`maint` ブランチを現在のブランチにマージしますが、自動的に新しいコミットを作成しない
```
$ git merge --no-commit maint
```
これは、マージにさらなる変更を含めたい場合や、独自のマージコミットメッセージを書きたい場合に使用できます。

このオプションを悪用して、実質的な変更をマージコミットにこっそり忍び込ませることは控えるべきです。リリース/バージョン名の更新のような小さな修正は許容されます。

マージ戦略

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

ort

これは、1つのブランチをプルまたはマージする際のデフォルトのマージ戦略です。この戦略は、3ウェイマージアルゴリズムを使用して2つのヘッドのみを解決できます。3ウェイマージに使用できる共通の祖先が複数ある場合、共通の祖先のマージ済みツリーを作成し、それを3ウェイマージの参照ツリーとして使用します。Linux 2.6カーネル開発履歴から取得された実際のマージコミットで実施されたテストにより、誤ったマージを引き起こすことなく、マージ競合が減少することが報告されています。さらに、この戦略は名前変更を伴うマージを検出および処理できます。検出されたコピーは利用しません。このアルゴリズムの名前は頭字語 ("Ostensibly Recursive’s Twin") であり、以前のデフォルトアルゴリズムである `recursive` の代替として書かれたという事実から来ています。

パスがサブモジュールである場合、マージの片側で使用されたサブモジュールコミットがマージの反対側で使用されたサブモジュールコミットの子孫である場合、Git は子孫へのファストフォワードを試みます。そうでない場合、Git はこのケースを競合として扱い、競合するサブモジュールコミットの子孫であるサブモジュールコミットが存在すれば、それを解決策として提案します。

ort 戦略は以下のオプションを受け付けます。

ours

このオプションは、競合するハンクを自分たち (our) のバージョンを優先して自動的にきれいに解決します。相手のツリーからの変更で、自分たちの側と競合しないものはマージ結果に反映されます。バイナリファイルの場合、内容全体が自分たちの側から取られます。

これは、相手のツリーが何を含んでいるかをまったく見ない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` も参照してください。

相手 (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>]

名前変更検出を有効にし、必要に応じて類似度閾値を設定します。これがデフォルトです。これは 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つのヘッドを解決するためのデフォルト戦略でした。

サブモジュールであるパスの場合、ort と同様の注意がこの戦略にも適用されます。

recursive 戦略は ort と同じオプションを受け付けます。ただし、ort が無視する (上記に文書化されていない) 3つの追加オプションがあり、これらは recursive 戦略で潜在的に役立ちます。

patience: `diff-algorithm=patience` の非推奨の同義語です。
diff-algorithm=[patience|minimal|histogram|myers]: マージ中に異なる diff アルゴリズムを使用します。これにより、重要でない一致する行 (異なる関数の括弧など) が原因で発生する誤ったマージを回避するのに役立ちます。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つ以上のヘッドがあるケースを解決しますが、手動解決が必要な複雑なマージは拒否します。主にトピックブランチのヘッドをまとめるために使用されます。複数のブランチをプルまたはマージする際のデフォルトのマージ戦略です。

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 よりも小さい競合領域を生成する傾向があります。もう一つの代替スタイル "zdiff3" は diff3 に似ていますが、競合領域の開始または終了付近に一致する行が現れる場合に、両側の一致する行を競合領域から削除します。

merge.defaultToUpstream

コミット引数なしでマージが呼び出された場合、現在のブランチに設定されているアップストリームブランチを、それらのリモート追跡ブランチに保存されている最後に観測された値を使用してマージします。`branch.<current branch>.remote` で指定されたリモート上のブランチ名を指定する `branch.<current branch>.merge` の値が参照され、その後 `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

リポジトリ内のファイルの正規表現が時間の経過とともに変化したこと (例: 以前のコミットではCRLF行末記号のテキストファイルを記録したが、最近のコミットではLF行末記号を使用していること) をGitに伝えます。そのようなリポジトリでは、3ウェイコンテンツマージが必要な各ファイルについて、Git は不要な競合を減らすために、マージを実行する前にコミットに記録されたデータを正規形式に変換できます。詳細については、gitattributes[5] の「Merging branches with differing checkin/checkout attributes」セクションを参照してください。

merge.stat

マージの最後に ORIG_HEAD とマージ結果の間の diffstat を出力するかどうか。デフォルトは 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
vscode
winmerge
xxdiff

merge.verbosity

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

merge.<driver>.name

カスタムの低レベルマージドライバの人間が読める名前を定義します。詳細については、gitattributes[5] を参照してください。

merge.<driver>.driver

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

merge.<driver>.recursive

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

git[1] スイートの一部

セットアップと設定

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

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

ブランチとマージ

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

検査と比較

パッチ適用

デバッグ

メール

外部システム

サーバー管理

ガイド

管理

低レベルコマンド (Plumbing Commands)

名前

概要

説明