ブランチのマージ — 意味、マージ方法とコンフリクト解決

Gitのマージとは

Gitのマージは、2つ以上の開発履歴を1つに結合する操作です。開発者がブランチをマージすると、Gitは自動的に共通の祖先（ベースコミット）を見つけ、両方のブランチからの変更を含む新しいマージコミットを作成します。Three-way mergeは、共通の祖先、最初のブランチ、2番目のブランチの3つの状態を比較する標準アルゴリズムです。

マージプロセスはgit mergeコマンドで開始されます。Gitはブランチの分岐点を特定し、ソースブランチからターゲットブランチに順次変更を適用します。変更が競合しない場合、Gitは設定に応じてfast-forwardを実行するか、マージコミットを作成します。Fast-forwardは、ターゲットブランチがソースブランチのコミットに単純に移動するシナリオです。

# ターゲットブランチに切り替えてマージ
git checkout main
git merge feature/payment-module

# 明示的なno-fast-forwardでマージ
git merge --no-ff feature/payment-module

# コンフリクトが複雑すぎる場合はマージを中止
git merge --abort

--no-ffフラグ（no fast-forward）は、fast-forwardが可能な場合でもマージコミットの作成を強制します。これにより、変更が別のブランチで行われたという情報が保持されます。多くのチームは、ブランチ履歴を明示的に維持するためにこのアプローチを好みます。

ブランチ統合の方法

Gitには3つの主要なブランチ統合戦略があり、それぞれ特定のシナリオに適しています。戦略の選択は、チームの文化とプロジェクト履歴の明確さの要件によって異なります。

Standard mergeは2つの親を持つマージコミットを作成します。完全な履歴は保持されますが、ブランチのグラフはより複雑になります。Squash mergeはフィーチャーブランチのすべてのコミットを1つにまとめ、ターゲットブランチの上に適用します。履歴は線形で明確になりますが、中間段階の情報は失われます。

Rebaseは完全なマージではありませんが、同じ結果を達成します。あるブランチの変更が別のブランチの上に移動されます。違いは、履歴が書き換えられることです。フィーチャーブランチのコミットは、ターゲットブランチの最新コミットの上に再作成されます。これにより完全に線形な履歴が得られますが、プッシュ時にforce pushが必要です。

マージコンフリクトの解決方法

マージコンフリクトは、ファイルの同じ行が2つのブランチで変更された場合に発生します。Gitは自動的にどちらのバージョンを保持するかを判断できず、開発者の介入が必要です。コンフリクトは、<<<<<<<、=======、>>>>>>>の特別なマーカーを使用してファイルに表示されます。

コンフリクト解決プロセスにはいくつかの手順が含まれます。まず、開発者は競合するファイルを開き、必要な変更を手動で選択します。単に1つのバージョンを選ぶだけでなく、両方の変更のロジックを理解し、正しい決定を下すことが重要です。ファイルを編集した後、コンフリクトマーカーを削除し、git addでステージングエリアに変更を追加します。

# 競合ファイルの一覧を表示
git status

# mergetoolを起動（例：VS Code、IntelliJ）
git mergetool

# すべてのコンフリクトを解決した後
git add .
git merge --continue

# またはマージを完全に中止
git merge --abort

ビジュアルマージツールを使用すると、コンフリクト解決が大幅に高速化されます。VS Code、IntelliJ IDEA、GitKrakenは、現在のブランチ、 incoming ブランチ、結果の3つのパネルを備えたインターフェースを提供します。git mergetoolツールは、競合するファイルごとに設定されたエディターを自動的に開きます。

複雑なコンフリクトを回避する最善の方法は、フィーチャーブランチをメインブランチと定期的に同期することです。開発者が1日に1回mainを自分のブランチにマージすれば、コンフリクトは小さく簡単に解決できます。1週間変更を蓄積すると、エラーのリスクが高い複雑なコンフリクトが発生します。

mergeの代わりにrebaseを使用するタイミング

Rebaseとmergeは変更を統合する2つの方法であり、その選択はチーム内でしばしば議論を引き起こします。Rebaseは履歴を書き換えながら、あるブランチのコミットを別のブランチの上に移動します。Mergeはブランチ履歴を保持しながら、新しいマージコミットを作成します。各アプローチには長所と制限があります。

Rebaseは、開発者がローカルのフィーチャーブランチで作業しており、Pull Requestを作成する前にクリーンな線形履歴を必要とする場合に適しています。Rebase後、すべてのコミットは不要なマージコミットなしに順番に並べられます。ただし、rebaseにはforce pushが必要であり、複数の人が同時に作業するブランチには適用できません。

• Rebase — クリーンな履歴が必要な個人のフィーチャーブランチ向け
• Merge — 共有ブランチとマージ時点の記録向け
• Squash — フィーチャーブランチに多数の小さなドラフトコミットがある場合

Gitの黄金律：既に共有リポジトリにプッシュされたコミットではrebaseを使用しないこと。これにより、共有ブランチの履歴が変更されず、他の開発者が重複したコミットや失われたコミットに遭遇しないことが保証されます。フィーチャーブランチをメインブランチに統合するには、Pull Requestを介したmergeを使用してください。

ブランチ統合のベストプラクティス

適切なマージプロセスは安定した開発の基盤です。現代のチームワークでは、マージはコンソールではなく、GitHubのPull RequestまたはGitLabのMerge Requestを介して行われます。PRはコードレビュー、自動CIチェックを通過し、その後初めてメインブランチにマージされます。

最初のプラクティス — すべてのチェックに合格した後にのみマージすること。CIパイプラインはプロジェクトをビルドし、テストを実行し、コード品質を検証する必要があります。少なくとも1つのチェックが失敗した場合、マージはブロックされます。最新のプラットフォーム（GitHub、GitLab）には組み込みの保護機能があります。ブランチプロテクションルールは、CIが失敗した場合に自動的にマージをブロックします。

2番目のプラクティス — 壊れたコードを決してマージしないこと。マージ前に、開発者は自分の変更がビルドを壊したり、既存の機能を退行させたりしないことを確認する必要があります。このために、自動テストとコードレビューが存在します。

3番目のプラクティス — マージ後にフィーチャーブランチをクリーンアップすること。マージ済みのブランチは削除する必要があります。これにより、混乱やリポジトリの乱雑さを防ぎます。GitHubはPRマージ後に自動的にブランチ削除を提案し、リポジトリ設定で自動削除を構成できます。