Git

git-merge 最終更新日: 2.50.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 によって使用され、あるブランチから別のブランチに変更をマージするために手動で使用することもできます。

以下の履歴が存在し、現在のブランチが 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: マージされる履歴が現在の履歴のすでに子孫である場合に、マージがどのように処理されるかを指定します。--ff がデフォルトですが、refs/tags/ 階層の自然な場所に格納されていない注釈付き (および署名付きの可能性のある) タグをマージする場合は --no-ff が想定されます。

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

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

--ff-only を指定すると、可能な場合、マージをファストフォワードとして解決します。不可能な場合、マージを拒否し、非ゼロのステータスで終了します。
-S[<key-id>]
--gpg-sign[=<key-id>]
--no-gpg-sign: 結果のマージコミットにGPG署名します。<key-id> 引数はオプションで、デフォルトはコミッターのIDです。指定する場合は、スペースなしでオプションに付加する必要があります。--no-gpg-sign は commit.gpgSign 設定変数と、以前の --gpg-sign の両方を打ち消すのに役立ちます。
--log[=<n>]
--no-log: ブランチ名に加えて、マージされる実際のコミットのうち最大 <n> 個の一行説明でログメッセージを埋めます。git-fmt-merge-msg[1] も参照してください。

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

--no-signoff オプションは、コマンドラインで指定された以前の --signoff オプションを打ち消すために使用できます。
--stat
-n
--no-stat: マージの最後に差分統計 (diffstat) を表示します。差分統計は設定オプション `merge.stat` によっても制御されます。

-n または --no-stat を指定すると、マージの最後に差分統計を表示しません。
--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: 操作開始前に一時的なスタッシュエントリを自動的に作成し、それをリファレンス 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 は、個別の git add で結果をインデックスにコミットする前に、rerere が何をしたかを再確認し、潜在的な誤マージを捕捉するための良い方法です。
--overwrite-ignore
--no-overwrite-ignore: マージ結果から無視されたファイルを黙って上書きします。これがデフォルトの動作です。--no-overwrite-ignore を使用すると中止されます。
--abort: 現在の競合解決プロセスを中止し、マージ前の状態を再構築しようとします。autostashエントリが存在する場合、それを作業ツリーに適用します。

マージ開始時にコミットされていない作業ツリーの変更があった場合、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 が停止した後、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 は「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 という名前の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 は、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 ブランチをマージし、オクトパスマージを作成します。
```
$ 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 の代替として作成されたという事実から来ています。

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

ort 戦略は以下のオプションを受け取ることができます

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] の「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> の非推奨の同義語です。

no-renames

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

histogram

diff-algorithm=histogram の非推奨の同義語です。

patience

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

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

マージ中に異なる diff アルゴリズムを使用します。これにより、重要でない一致行 (異なる関数の括弧など) が原因で発生する誤マージを回避できる場合があります。git-diff[1] の --diff-algorithm も参照してください。ort はデフォルトで diff-algorithm=histogram を使用するのに対し、通常の diff は現在 diff.algorithm 設定に従うことに注意してください。

subtree[=<path>]

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

recursive

これは現在 ort の同義語です。v2.49.0 までは別の実装でしたが、v2.50.0 で ort を意味するようにリダイレクトされました。以前の recursive 戦略は、Git v0.99.9k から v2.33.0 まで、2つのヘッドを解決するためのデフォルト戦略でした。

resolve

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

octopus

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

ours

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

subtree

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

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

設定

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

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

merge.conflictStyle

マージ時に競合するハンクが作業ツリーファイルにどのように書き出されるかを指定します。デフォルトは「merge」で、<<<<<<< 競合マーカー、片側による変更、======= マーカー、もう一方の側による変更、そして >>>>>>> マーカーを表示します。代替スタイル「diff3」は、||||||| マーカーと ======= マーカーの前に元のテキストを追加します。「merge」スタイルは、元のテキストが除外されるためと、両側でサブセットの行が一致する場合にそれらが競合領域から除外されるため、diff3 よりも小さな競合領域を生成する傾向があります。もう1つの代替スタイル「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

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

merge.suppressDest

この多値設定変数に統合ブランチの名前と一致するグロブを追加すると、これらの統合ブランチへのマージに対して計算されるデフォルトのマージメッセージは、タイトルから「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

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

merge.stat

マージの最後に 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
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[1]スイートの一部

セットアップと設定

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

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

ブランチとマージ

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

検査と比較

パッチ適用

デバッグ

メール

外部システム

サーバー管理

ガイド

管理

配管コマンド

名前

概要

説明