Gitを使って開発をしていると、必ず登場するのがブランチの運用です。特に「開発用のブランチで作業をして、本番用ブランチに統合する」といった流れは、日常的に行われています。その際に活用されるのが「git merge」コマンドです。この記事では、git mergeの基本的な使い方から、よくあるトラブルへの対処法まで、初心者にもわかりやすく解説します。ブランチ統合をスムーズに行いたい方や、マージの仕組みをしっかり理解しておきたい方に役立つ内容です。
Gitにおけるブランチとマージの関係とは？
Gitでは、複数人での並行開発や、新機能の開発、バグ修正などの目的で「ブランチ」を使います。ブランチは、開発の流れを分岐させることで、他の開発に影響を与えずに作業ができる便利な仕組みです。
しかし、最終的にはすべての変更をひとつの主流ブランチ（例：mainやmaster）にまとめる必要があります。その作業が「マージ（merge）」です。git mergeコマンドは、あるブランチの内容を現在のブランチに統合するためのコマンドです。
例えば、feature/loginというブランチで開発した機能をmainブランチに反映したい場合、以下のように実行します。
git checkout main
git merge feature/login
この2ステップで、feature/loginブランチの内容がmainに取り込まれます。
git merge の基本的な使い方
git mergeは、現在チェックアウトしているブランチに、指定したブランチの変更を統合するコマンドです。基本的な構文は以下の通りです。
git merge <統合したいブランチ名>
例：developブランチにfeatureAブランチをマージする
git checkout develop
git merge featureA
このとき、Gitは自動で差分を検出し、衝突がなければ自動的にマージが完了します。
fast-forwardマージと通常のマージの違い
Gitのマージには、いくつかのタイプがあります。代表的なのが「fast-forwardマージ」と「通常のマージ（マージコミットあり）」です。
fast-forwardマージとは？
対象ブランチに変更がない場合、Gitは履歴をそのまま早送り（fast-forward）することでマージを行います。
git checkout main
git merge featureA
このとき、mainに何も変更がなければ、featureAの最新状態に「追いつく」だけでマージが完了します。コミット履歴がシンプルに保たれるというメリットがあります。
通常のマージ（マージコミットあり）
両方のブランチに変更がある場合、Gitはマージコミットを作成します。
Merge branch 'featureA' into 'main'
このようなマージコミットによって、複数のブランチが統合されたタイミングが明確になります。
コンフリクト（衝突）が発生した場合の対処法
複数のブランチで同じファイルの同じ箇所を変更していると、「コンフリクト（conflict）」が発生することがあります。
マージを実行した際、以下のようなメッセージが出たらコンフリクトです。
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
この場合、対象ファイルを開くと、以下のような表記になります。
<<<<<<< HEAD
現在のブランチの内容
=======
マージ先ブランチの内容
>>>>>>> featureA
これを手動で修正して、以下のように整えた後、
bashコピーする編集するgit add index.html
git commit
という流れでマージ完了となります。
git mergeとgit rebaseの違い
git mergeとよく比較されるのがgit rebaseです。どちらもブランチを統合する目的ですが、履歴の扱いに違いがあります。
| コマンド | 特徴 |
|---|---|
git merge | 履歴を残す（マージコミットができる） |
git rebase | 履歴を1本化（まるで1つの流れで開発したように） |
チームでの共同開発では、履歴の透明性を重視するためgit mergeが使われることが多いですが、個人開発やクリーンな履歴を重視したい場合はgit rebaseが使われることもあります。
マージ前に確認すべきこと
マージをする前に、以下のことを確認しておくと安心です。
- 最新の状態に更新しておく
マージ先のブランチとマージ元のブランチ、両方を最新の状態にgit pullしておきましょう。 - 差分を確認する
git diff ブランチ名で、どんな変更が加えられるのか事前にチェックできます。 - テストを実行する
マージ前後にアプリケーションのテストを行い、動作確認をするのが望ましいです。
よくあるエラーとその対処法
マージ済みと認識されない
fatal: refusing to merge unrelated histories
→ 全く関係のない2つの履歴をマージしようとしている時に出るエラーです。--allow-unrelated-historiesオプションを使って回避可能です。
git merge featureB --allow-unrelated-histories
マージ後のビルド失敗
マージがうまくいったように見えても、アプリケーションがビルドできないこともあります。マージ前にテスト、CI/CDの確認は忘れずに。
git mergeのベストプラクティス
- 定期的にマージしておく
長期間分岐したブランチ同士をマージすると、コンフリクトが増えやすくなります。こまめにマージを行うことで、トラブルを減らせます。 - PR（Pull Request）を活用する
チームでの開発では、マージはPRを通じて行うと、レビューやテストのステップを踏みやすく、ミスも防げます。 - 命名規則とブランチ運用ルールを定める
feature/,bugfix/,release/など、ブランチ名に意味を持たせることで、誰が何をしているか把握しやすくなります。
まとめ
git mergeは、Gitを使ううえで欠かせない基本操作のひとつです。単純な統合だけでなく、コンフリクト対応や履歴管理など、注意点も多くあります。しかし、正しい理解と運用をすることで、開発効率やチーム連携を大きく向上させることができます。
ぜひ今回の内容を参考に、よりスムーズなブランチ統合を目指してみてください。次回はgit rebaseについても詳しく解説予定です。お楽しみに！