【Git】マージ（Merge）

マージ（Merge／Git）とは、バージョン管理システムのGitにおいて、別々のブランチで進めた変更を、ひとつのブランチにまとめて合流させる操作のことです。新しい機能の開発や不具合の修正を別のブランチで進めたあと、その成果を本流に取り込むときに使われます。

現実世界に例えると、マージは本の原稿を章ごとに別の人が書き進め、最後に1冊の原稿へ綴じ合わせる作業のようなものです。それぞれが書き足した部分を取りこぼさずに集め、同じページを2人が書き換えていれば、どちらを採用するかを決めて仕上げます。

マージ図解

※画像をクリックすると拡大表示します。

使われる流れです。Gitでは、本流のブランチから作業用のブランチを分け、そこで変更を重ねてから本流へ戻すという進め方が一般的です。この「戻す」操作がマージです。複数の人が並行して作業しても、それぞれの成果を最後にまとめられるのは、マージの仕組みがあるからです。

いちばん単純な形です。作業用のブランチを分けてから本流に何も変更がなかった場合、本流の位置を作業用のブランチの先頭まで進めるだけで合流が完了します。これを「ファストフォワード（早送り）」と呼びます。新しい記録は作られず、履歴は一本の線のまま残ります。

よくある形です。本流と作業用のブランチの両方で変更が進んでいた場合、Gitは分かれる前の共通の地点と、両方の最新の状態を比べて、変更を組み合わせます。その結果は「マージコミット」という新しい記録として残り、2つの流れが合わさったことが履歴から分かります。

避けて通れない場面です。2つのブランチで同じファイルの同じ箇所が別々に書き換えられていると、Gitはどちらを採用すべきか判断できず、「コンフリクト（競合）」として作業を止めます。ファイルには両方の内容が目印付きで書き込まれるので、人が中身を確かめて正しい形に直し、改めて記録します。

似た操作との比較です。リベースは、作業用のブランチの変更を、本流の最新の状態の上に付け替えて、履歴を一本の線に整える操作です。履歴が見やすくなる一方、記録を書き換えるため、ほかの人と共有済みのブランチで行うと混乱を招きます。経緯をそのまま残すマージと、目的に応じて使い分けます。

チーム開発での実際です。GitHubなどのサービスでは、作業用のブランチの変更を「プルリクエスト」として提出し、ほかの人の確認を受けてから、画面のボタンでマージするのが一般的です。このとき、マージコミットを作る、1つにまとめる、付け替えるといった方法を選べるようになっています。

困ったときの対処です。コンフリクトの解決に迷ったら、マージの途中で操作を取り消し、合流する前の状態に戻せます。マージが完了したあとに問題が見つかった場合は、そのマージを打ち消す新しい記録を作って元に戻す方法があります。履歴を残したまま戻せるため、共有済みのブランチでも安全です。