【Git】ブランチのマージ戦略！基本からコンフリクト解決までを徹底解説
はじめに
こんにちは！開発作業でGitを使っていると、必ずと言っていいほど登場するのがブランチのマージ作業ですよね。
今回は、メインブランチ（main）の変更内容を開発用ブランチ（dev）に取り込む基本的な手順から、--no-ffや--squashといった便利なオプション、そして誰しも一度は頭を抱える「コンフリクト」の解決方法までを、備忘録としてまとめてみました。
この記事が、皆さんのGit運用の一助となれば幸いです。
目次
1. 基本的なマージ手順
まずは、mainブランチの変更をdevブランチに取り込むための基本的な流れを確認しましょう。
① devブランチに切り替え
何よりも先に、マージ先のブランチ（今回はdev）に移動します。
git checkout dev
② 最新の状態を取得
リモートリポジトリがある場合、他の人が更新している可能性があるので、必ず最新の状態を取得しておきましょう。
git pull origin dev
③ mainブランチをマージ
いよいよマージを実行します。以下のコマンドで、devブランチにmainブランチの変更が取り込まれます。
git merge main
注意: マージを実行する前に、
git log --oneline --graph --allなどでコミット履歴を確認し、どのブランチがどこから分岐しているかを把握しておくことを強くお勧めします。
2. マージの種類とオプションを使いこなす
git mergeにはいくつかオプションがあり、これらを使い分けることでコミット履歴を綺麗に保つことができます。
① Fast-forward マージ（早送りマージ）
devブランチからmainブランチが分岐した後、devブランチに新しいコミットがない場合、GitはデフォルトでFast-forwardマージを行います。これは、devブランチのポインタをmainブランチの最新コミットに移動させるだけのシンプルなマージです。コミット履歴が一直線になり、マージしたという履歴は残りません。
# デフォルトの挙動
git merge main
② --no-ff（マージコミットを必ず作成）
Fast-forwardが可能な状況でも、あえてマージコミットを作成したい場合があります。--no-ffオプションを使うと、「mainブランチの機能をマージした」という事実をコミットとして明確に残すことができます。
git merge --no-ff main
これにより、後から履歴を見たときに、どこで機能追加のブランチが合流したのかが一目瞭然になります。
③ --squash（複数のコミットを1つにまとめる）
作業ブランチ（main）で細かくコミットを分けすぎた場合、そのままマージするとdevブランチの履歴が煩雑になってしまいます。--squashオプションを使うと、mainの複数のコミットを1つのコミットとしてまとめた上で、devブランチに取り込むことができます。
git merge --squash main
このコマンドを実行すると、変更がステージングされた状態になるので、手動でコミットを実行する必要があります。
# squashマージの後、手動でコミット
git commit -m "feat: merge main branch features"
メインブランチの履歴をクリーンに保ちたい場合に非常に有効です。
3. コンフリクトが発生した場合の対処法
複数のブランチで同じファイルの同じ箇所を編集していると、マージ時にコンフリクト（競合）が発生します。初めて遭遇すると焦りますが、落ち着いて対処すれば大丈夫です！
① コンフリクトしたファイルを確認
まずはgit statusコマンドで、どのファイルがコンフリクトしているのかを確認しましょう。
git status
Unmerged paths:というセクションに、コンフリクトしたファイルが表示されます。
② ファイルを編集してコンフリクトを解決
VS Codeなどのエディタで対象ファイルを開くと、以下のようなコンフリクトマーカーが表示されています。
<<<<<<< HEAD
（devブランチでの変更内容）
=======
（mainブランチでの変更内容）
>>>>>>> main
<<<<<<<から>>>>>>>までを、どちらの変更を採用するのか、あるいは両方を残すように手動で編集し、マーカー自体は削除します。
③ 解決後にマージを完了
ファイルの修正が終わったら、通常通りaddしてcommitします。
git add .
git commit
コミットメッセージはGitが自動で用意してくれますが、必要に応じて編集してください。これでコンフリクトの解決とマージは完了です。
4. マージ後の推奨手順
マージが成功したら、後片付けと最終確認を行いましょう。
① ビルドとテストの実行
マージによって意図しない不具合が発生していないかを確認するため、ビルドやテストを実行します。
# プロジェクトのルートディレクトリに移動
cd path/to/your/project
# 例：npmプロジェクトの場合
npm run build
npm run lint -- --fix
npm run test:e2e
② リモートにプッシュ
ローカルでの確認が完了したら、変更内容をリモートリポジトリにプッシュします。
git push origin dev
③ 不要になったブランチを削除
マージが完了し、mainブランチが不要になった場合は削除しておきましょう。
git branch -d main
まとめ
今回はGitのブランチマージについて、基本的な手順から応用までをまとめてみました。
-
マージの基本は
git checkout <マージ先>→git merge <マージ元>。 -
コミット履歴を綺麗に保つには
--no-ffや--squashが有効。 -
コンフリクトは
git statusで確認し、ファイルを直接編集して解決する。 - マージ後はテストを実行し、不要なブランチは削除する。
これらの手順を使いこなし、安全で効率的な開発を進めていきましょう。
それではまた！