次の項目は別ページに分割しました。
関連ページ：
Git に関する基本的な情報は次のページにまとめています。
マージ
公式サイト：
git-merge | Git Documentation [Official]
使い方
過去に master からフォークしたトピックブランチ topic を、元の本流のブランチ master にマージ (統合) する。
$ git checkout master $ git merge topic
master のコミット G に、topic の コミット C をマージして、マージコミット H を作成すると下の図のようなコミットグラフの状態となる。
A---B---C topic
/ \
D---E---F---G---H master
参考：
ブランチとマージの基本 | Pro Git book [公式]
概要
参考：
マージ方向
参考：
git で双方向に merge してるとひどいはまり方をするときがある件 | はこべにっき
merge two branches: what direction? – Stack Overflow
Git Cherry-pick vs Merge Workflow – Stack Overflow
Git merge in wrong direction – Stack Overflow
コンフリクト
コンフリクトが発生した場合、コード内にこのように手動でマージが必要な部分が生成される。
<<<<<<< HEAD:index.html <div id="footer">contact : email.support@github.com</div> ======= <div id="footer"> please contact us at support@github.com </div> >>>>>>> iss53:index.html
<<<<<<< から ======= までが HEAD つまり master などのマージされている側のブランチ由来のコードであり、======= から >>>>>>> までが現在マージしている新しいコミット由来の更新されたコードが含まれている。
コードの重複を解消してどちらかのコードを選択するか、あるいは融合したコードに編集する必要がある。
参考：
ブランチとマージの基本 | Pro Git book [公式]
diff3 スタイル
コンフリクト発生時に、3ウェイマージ表示で共通祖先のコードが確認できるように、merge.conflictStyle を diff3 スタイルに変更する。
$ git config --global merge.conflictStyle diff3
||||||| から ======= の間に共通の祖先のコードが挿入されるようになる。
This is the first sentence from branch 'master'. <<<<<<< HEAD This is the modified second sentence from branch 'master'. This is the third sentence from branch 'master'. ||||||| merged common ancestors This is the second sentence from branch 'master'. ======= This is the second sentence from branch 'master'. This is the third sentence from branch 'hotfix'. >>>>>>> hotfix
コミット B とコミット C の共通の祖先がコミット A の場合に、コミット C をコミット B にマージしてマージコミット M を作成するとする。
C--- fix
/ \
...---A---B---M master
次のようなマージファイルが作成される。
<<<<<<< HEAD (ours) Code from B ||||||| common ancestor (base) Code from A ======= Code from C >>>>>>> fix (theirs)
参考：
3ウェイマージについて／マージの中断とマージコンフリクトについて | kledgeb
Git の merge.conflictStyle を merge から diff3 に変更したら、マージコンフリクトがより解決しやすくなった | yu8mada
Fast-Forward Merge vs Three-Way Merge | Kotesh Meesala
3-way merge とは具体的にどのようなアルゴリズムですか？ – スタック・オーバーフロー
Why is a 3-way merge advantageous over a 2-way merge? – Stack Overflow
コンフリクトを解消する
参考：
Git のマージコンフリクトを解決する方法 | yu8mada
削除したファイルのコンフリクトを解消する
マージを実行した時、片方のコミットでファイルが変更され、別のコミットでファイルを削除していた場合に、コンフリクトが発生する。
基本的なマージ方針として、考えられる選択肢は2つある。
[1] 更新ファイルを採用する
変更されたファイルを追加してコミットする。
$ git add conflicted_file $ git commit --amend
[2] ファイルを削除する
あるいは、Git 管理から当該ファイルを取り除いて、ファイルの削除を受け入れる。
$ git rm conflicted_file $ git commit --amend
参考：
Git で 削除したファイルのコンフリクト解消方法 – Qiita
How do I fix a merge conflict due to removal of a file in a branch? – Stack Overflow
git checkout --ours / --theirs
マージ元のファイルをチェックアウトする。
$ git checkout --ours the_confilicted_file
マージ先のファイルをチェックアウトする。
$ git checkout --theirs the_confilicted_file
参考：
マージ時のコンフリクトで片側の変更だけ適用する方法 – Qiita
マージのコンフリクトで片方ブランチのファイル変更内容を採用 | EasyRamble
マージでバイナリファイルがコンフリクトした場合の Git の動作と対処方法 | アインシュタインの電話番号
Git でマージしたバイナリファイルがコンフリクトした場合の解決策｜DIGITAL SQUADブログ
マージでコンフリクトした際にどちらかのブランチの内容を適用 | いろいろ備忘録日記
git でコンフリクトした時の ours / theirs – Qiita
git でコンフリクトが起きて、一方を全部優先する方法 | MasK の permission denied.
git でコンフリクトが起きた時に面倒なので一方のコミット内容を全て優先したい！ – teratail
ストラテジー
--strategy オプション (もしくは、短縮オプション -s) で指定する。
ortresolverecursiveoctopusourstheirssubtree
参考：
Git 2.33 がリリース／新しいマージ戦略 merge-ort の導入 | ソフトアンテナ
merge-strategies | Git Documentation [Official]
-s / --strategy – git-merge | Git Documentation [Official]
merge -X ours / theirs
再帰マージにおいて、コンフリクト発生時に優先するブランチをオプションで指定する。
参考：
git merge でコンフリクトしたとき片方のブランチの変更を優先させる | TaillookTech
Git で再帰的ストラテジでマージする時のストラテジオプション ours と theirs の違い | yu8mada
Force Git to always choose the newer version during a merge? – Stack Overflow
Git merge with force overwrite – Stack Overflow
git merge recursive theirs, how does it work? – Stack Overflow
Is there a “theirs” version of “git merge -s ours”? – Stack Overflow
-s ours
参考：
master ブランチを別のブランチに書き換え方法 – Qiita
オクトパスマージ
fix1、fix2、fix3 をまとめて master に統合する。(ファストフォワードマージのみが可能)
$ git checkout master $ git merge -s octopus fix1 fix2 fix3
コンフリクトが発生した場合にマージを中止して、ブランチを元の状態に戻す。
$ git reset --hard HEAD
参考：
Octopus マージストラテジーでマージを行う | kledgeb
Octopus マージストラテジーでマージを中止する | kledgeb
git で複数のブランチを同時に Non Fast Forward マージする | YoshinoriN’s Memento
merge -s theirs
参考：
Git merge -s theirs: Simply? – Stack Overflow
git command for making one branch like another – Stack Overflow
Is there a “theirs” version of “git merge -s ours”? – Stack Overflow
git pull におけるコンフリクト
参考：
git pull を強制し、リモートでローカルを上書きする方法 | WWW クリエイターズ
git merge 後の commit に -m を使ってはいけない | The Diary of Aska
マージ後に変更履歴を確認する
参考：
git log でマージしたファイルを確認する | 作業ノート
checkout せずに merge する
参考：
untracked working tree files エラー
マージ先でトラッキングしていないファイルの上書きが発生する為にマージできない。
参考：
untracked file を削除するためには git clean を使う – Qiita
Tips
I’ve said this before, and apparently I need to say this again: if you cannot be bothered to explain *WHY* a merge exists, then that merge is buggy garbage by definition.
—— LKML
参考：
Linus Torvald s氏、Git のマージに関し「マージについて説明できないのならやらないほうがいい」ゴミだからとアドバイス | ソフトアンテナ
rerere
参考：
コンフリクトの解決を記録して再適用する git rerere – Qiita
Rerere | Pro Git book [Official]
Git Merge Distinct
リポジトリ：
tpettersen/git-merge-distinct – Bitbucket
入手：
参考：
git merge-distinct – Staging Multiple Branches with Octopus-Merge | Atlassian Developer Blog