マージ

友だちとグループ課題をしたとき、それぞれ担当パートを別々に書いた経験があると思います。Aさんは序論、Bさんは本論、Cさんは結論を担当して、各自のパソコンで文書を作りますよね。全員の作業が終わったら、最後に1つのファイルへ内容をコピーして集めることで、最終レポートが完成します。

ソフトウェア開発でもまったく同じ方法を使います。プログラマーは大きなプログラムを作るとき、メインのコードから枝を伸ばすように独立した作業スペースを作り、それぞれ機能を実装します。バージョン管理ツールのGit（ギット）では、こうして分けた作業の流れを「ブランチ（Branch）」と呼びます。

自分のスペースで開発とテストを終えたら、完成したコードを中心の幹に合流させなければなりません。こうして枝分かれしていた作業内容を、基準となる幹に安全に集める作業をマージと呼びます。

文章をまとめるとき、人が1文ずつ目で見比べながら貼り付けると、大事な内容を抜かしたりミスをしたりしやすいものです。でもバージョン管理ツールは、それぞれがどの行を追加・削除したのか、変更内容を比べて自動でまとめてくれます。

たとえば、さくらさんは10行目の誤字を直し、たけしさんは50行目に新しい文を追加したとします。2人が触った場所はまったく違うので、プログラムは2人の修正を重ならないように順番に合わせてくれます。

もう少し正確に言うと、Gitは2つの作業が枝分かれした「共通の祖先の時点」を基準にします。分かれたあとにそれぞれがどの行を直したかを確認し、衝突がない部分は自動で1つの完成版に編み上げます。ただし、文字どうしが衝突しなかったからといって、合体したプログラムが正しく動く保証はないので、マージのあとにもう一度テストします。

もし2人が同じファイルの同じ行を、それぞれ違う内容に修正したらどうなるでしょうか。1人がファイルを削除して、もう1人がそのファイルを修正した場合も同じです。コンピューターはどちらのコードが正しいのか自分では判断できないので、合体作業をいったん止めて助けを求めます。

この状況をマージコンフリクト（Merge Conflict／マージの衝突）と呼びます。コンピューターが勝手に片方のコードを消して上書きすると、深刻なエラーが起きかねません。そこで、人に直接確認してもらうために立ち止まる安全装置になっているのです。

このとき開発者は、2人が変更したコードを並べて見比べながら、どちらのコードを最終版に残すかを自分で選びます。衝突した部分を適切に直して整えてはじめて、マージ作業が安全に完了します。