実用 Git 第3版

6章マージ

Gitは分散バージョン管理システムなので、中央のリポジトリを設けることなく、地理的に離れた位置にいる開発者たちが独立に変更を加え、記録することを認め、複数の開発者たちが任意のタイミングでそれぞれの変更を1つにまとめることも認める。これは、複数の開発ラインを1つにまとめる操作であり、Gitはこれにマージ（merge）という正式名称を与えている。

この章では、いくつかの単純なマージの例を通じて複数の開発ラインをマージする方法を説明するとともに、マージコンフリクトを解決するためのテクニックを紹介する。Gitでのマージ戦略についても説明し、マージ操作が実行されたときにGitオブジェクトストアで何が起きるかも示す。

6.1　マージの技術的な意味

Gitのマージは、複数のブランチのコミット履歴を1つにまとめる。たいていの場合、マージは2個のブランチを統一するだけに留まるだろうが、Gitは同時に3個以上のブランチをマージすることもサポートしている。

マージは、単一のリポジトリのなかで行わなければならない。つまり、マージ対象のすべてのブランチは、同じリポジトリに含まれていなければならない。しかし、ブランチがどのようにしてそのリポジトリに含まれるようになったかは重視されない（「11章　リモートリポジトリ」で示すように、Gitはほかのリポジトリを参照するためのメカニズムやカレントリポジトリにリモートブランチを取り込むためのメカニズムを提供している）。

あるブランチにおける変更が別のブランチにおける変更との間でコンフリクト（双方が両立できないような矛盾）を起こさなければ、Gitはマージした結果を計算し、新しい統一された状態を表す新コミットを作る。しかし、ブランチの間にコンフリクトがある場合には、Gitは対立を解決しない。代わりに、インデックスでコンフリクトを起こす変更に「未マージ（unmerged）」のマークをつけ、開発者に解決を委ねる（「 ...