【ITニュース解説】Git Merge Explained with One Clear Example

システム開発では、複数のエンジニアが協力して一つのプロジェクトを進めることが一般的である。この時、各々がバラバラに作業を進めてしまうと、変更内容の管理が困難になり、衝突や間違いが頻繁に発生する。このような問題を解決するために利用されるのが、バージョン管理システムであるGitだ。Gitは、ファイルの変更履歴を効率的に管理し、複数のエンジニアが同時に作業しても、それぞれの変更を安全に統合できる仕組みを提供する。

Gitにおける「ブランチ」という概念は、プロジェクトのコードベースから派生した独立した作業ラインのようなものだ。新しい機能の開発やバグ修正を行う際、既存の安定版コード（通常はmainやmasterと呼ばれるブランチ）を直接変更するのではなく、そこから新しいブランチを作成し、そのブランチ内で作業を進める。これにより、新しい作業が既存の安定したコードに影響を与えることなく、独立して開発を進められる利点がある。

開発が完了し、テストも問題ないと判断されたら、その新しい機能や修正を元の安定版コード、つまりmainブランチに統合する必要がある。この統合の操作を「マージ（merge）」と呼ぶ。git mergeコマンドは、異なるブランチで行われた変更を一つにまとめ上げるための、Gitの非常に重要な機能の一つだ。

マージの方法には、大きく分けて二つの主要なパターンがある。一つは「ファストフォワードマージ（fast-forward merge）」、もう一つは「スリーウェイマージ（3-way merge）」である。

ファストフォワードマージは、特定の条件下で発生するマージの形式だ。このマージが適用されるのは、マージしようとしている二つのブランチのうち、片方のブランチの先端がもう片方のブランチの直接の「子孫」である場合、つまり、マージ先のブランチが、マージ元のブランチから見て追加のコミットしか持っていない場合に限られる。例えば、mainブランチからfeature-Aブランチを作成し、feature-Aブランチでいくつかのコミットを追加した後、mainブランチには何もコミットが追加されていない状況を想像してみよう。この場合、feature-Aをmainにマージする際、Gitは単にmainブランチが指し示すコミットのポインタをfeature-Aの最新コミットに移動させるだけでマージを完了できる。mainの先端がfeature-Aの先端へと「進む」イメージだ。この種類のマージでは、特別な「マージコミット」は作成されない。履歴が一直線につながっているように見えるため、見た目がシンプルになるという特徴がある。

一方、スリーウェイマージは、ブランチが分岐し、それぞれのブランチで独立したコミットが追加されている場合に発生する。例えば、mainブランチからfeature-Bブランチを作成した後、mainブランチにも新しいコミットが追加され、同時にfeature-Bブランチにも独自のコミットが追加された状況がこれにあたる。この場合、mainブランチの先端、feature-Bブランチの先端、そしてこれら二つのブランチが分岐した「共通の祖先」となるコミット、この三つの地点（three-way）をGitが比較し、変更内容を統合する。このプロセスを経て、Gitは新しい「マージコミット」を作成する。このマージコミットは、どのブランチのどのコミットが統合されたかという情報を記録し、ブランチが実際に結合されたという明確な証拠を履歴に残す。これにより、後から履歴を追跡する際に、どこでどのような統合が行われたかを一目で理解できる。スリーウェイマージでは、異なるブランチで同じファイルの同じ行が変更されていたり、同じ名前のファイルが異なるブランチで作成・削除されたりした場合に「コンフリクト（競合）」が発生することがある。コンフリクトが発生すると、Gitは自動的にマージを完了できず、どちらの変更を採用すべきか、あるいは両方の変更をどのように組み合わせるべきか、エンジニアに手動での解決を求める。これは、Gitが提供する安全なバージョン管理の重要な側面の一つだ。

ニュース記事の例では、まさにこれら二種類のマージが、mainブランチに複数のフィーチャーブランチを統合するシナリオで説明されている。まず、最初のフィーチャーブランチ（例えばfeature-A）をmainにマージする。もしmainブランチがfeature-Aが作成された時点から何も更新されていない場合、これはファストフォワードマージとなる可能性が高い。その結果、mainの履歴はfeature-Aの履歴の続きとして、一本の線のように見えるだろう。次に、別のフィーチャーブランチ（例えばfeature-B）をmainにマージする。この時、feature-Bブランチが作成されてから、既にfeature-Aのマージによってmainブランチが更新されている場合、mainとfeature-Bは共通の祖先から分岐し、それぞれが独自の更新を持っている状態となる。このため、このマージはスリーウェイマージとなり、新しいマージコミットが作成され、履歴上は二つのブランチが合流する形として記録される。

このようにgit mergeは、開発者が協力してプロジェクトを進める上で不可欠なツールであり、その種類と動作原理を理解することは、システムエンジニアとしてGitを効果的に活用するための第一歩となる。それぞれのマージがどのような状況で発生し、どのような履歴を残すのかを把握することで、より安全で効率的な開発ワークフローを構築できるようになる。