Gitブランチ入門｜branch・merge・プルリクエストの使い方とGitHub Flowを解説

ブランチとは何か

Gitのブランチを理解するのに便利なのが「鉄道路線の分岐」の例えです。

電車は本線（main）から支線（feature branch）が分岐して、それぞれ独立して走れます。支線での工事が終わったら本線に合流（merge）する、というイメージがそのままGitのブランチの仕組みに当てはまります。

ブランチを使う前の問題点：

新機能を試しているときにバグが見つかると、どっちを優先するか困る
複数人で同じファイルを同時に編集すると混乱する
「この機能はやめよう」となったとき、コードを元に戻すのが大変

ブランチを使うことで解決できること：

新機能・バグ修正を独立した「作業スペース」で行える
本番コード（main）を常に安全な状態に保てる
複数人が並行して別々の機能を開発できる

ブランチの基本コマンド

ブランチの一覧確認

# ローカルブランチの一覧を表示
git branch

# リモートを含む全ブランチを表示
git branch -a

出力例：

* main          # * が現在いるブランチ
  feature/login
  fix/header-bug

ブランチの作成

# ブランチを作成する（切り替えはしない）
git branch feature/user-profile

# ブランチを作成して、同時にそのブランチに切り替える（推奨）
git switch -c feature/user-profile

# 旧来のコマンド（現在も使えるが switch が推奨）
git checkout -b feature/user-profile

ブランチの切り替え

# 指定ブランチに切り替える（新しい書き方）
git switch main

# 旧来の書き方
git checkout main

ブランチの削除

# マージ済みのブランチを削除（安全）
git branch -d feature/user-profile

# 強制削除（マージしていなくても消える）
git branch -D feature/user-profile

# リモートブランチを削除
git push origin --delete feature/user-profile

ブランチでの作業フロー

ブランチを使った基本的な作業の流れを順番に説明します。

# 1. mainブランチの最新状態を取得
git switch main
git pull origin main

# 2. 作業用ブランチを作成して切り替え
git switch -c feature/add-contact-form

# 3. ファイルを編集する（ここで実際のコーディング）
# ... 作業 ...

# 4. 変更をステージングしてコミット
git add src/components/ContactForm.tsx
git commit -m "feat: お問い合わせフォームコンポーネントを追加"

# 5. さらに変更とコミットを繰り返す
# ... 追加の作業 ...
git add .
git commit -m "feat: フォームのバリデーション処理を実装"

# 6. リモートにプッシュ
git push -u origin feature/add-contact-form

マージ（merge）の仕組み

マージとは、あるブランチの変更を別のブランチに取り込む操作です。

# mainブランチに切り替えてから、featureブランチをマージする
git switch main
git merge feature/add-contact-form

マージには主に2種類の方法があります。

Fast-forward merge（早送りマージ）： mainブランチに新しいコミットがない場合、ブランチのコミットをそのままmainの先に追加します。

3-way merge（3者マージ）： mainとfeatureブランチの両方に新しいコミットがある場合、共通の祖先を基点に両者の変更を統合した「マージコミット」を作成します。

# マージコミットを強制的に作成する（履歴を残したい場合）
git merge --no-ff feature/add-contact-form -m "Merge: お問い合わせフォームの追加"

コンフリクト（競合）の解消方法

複数人が同じファイルの同じ箇所を編集したとき、Gitは自動的にマージできず「コンフリクト（競合）」が発生します。

コンフリクトが発生すると、該当ファイルに以下のようなマーカーが挿入されます。

<<<<<<< HEAD
// こちらはmainブランチ（現在のブランチ）の内容
const title = '旧タイトル';
=======
// こちらはfeatureブランチの内容
const title = '新しいタイトル';
>>>>>>> feature/update-title

解消の手順：

# 1. コンフリクトしているファイルを確認
git status
# both modified: src/components/Header.tsx

# 2. ファイルを開いて手動で編集する
# <<<<<<< から >>>>>>> までのマーカーを削除して、正しい内容に書き直す

# 例：featureブランチの変更を採用する場合
const title = '新しいタイトル';

# 3. 解消したファイルをステージングしてコミット
git add src/components/Header.tsx
git commit -m "fix: タイトルのコンフリクトを解消"

VS CodeのGit機能を使うと、コンフリクト箇所がグラフィカルに表示され、ボタンひとつで「現在のブランチを採用」「マージ元を採用」「両方を採用」を選べるので、手動編集より簡単です。

GitHub上でのプルリクエスト

プルリクエスト（PR）とは、「自分が作業したブランチをmainに取り込んでください」とチームメンバーに依頼する仕組みです。コードレビューの場としても使われます。

PRの作成手順

# 1. 作業ブランチをリモートにプッシュ
git push -u origin feature/add-contact-form

GitHubのリポジトリページを開く
「Compare & pull request」ボタンをクリック
PRのタイトルと説明を記入する
「Create pull request」をクリック

良いPRの書き方

## 概要
お問い合わせフォームコンポーネントを追加しました。

## 変更内容
- `ContactForm.tsx`：フォームコンポーネントの作成
- `ContactForm.test.tsx`：バリデーションのテスト追加
- `app/contact/page.tsx`：フォームページの作成

## 動作確認
- [ ] フォーム送信が正常に動作する
- [ ] バリデーションエラーが正しく表示される
- [ ] スマホ表示が崩れていない

## スクリーンショット
（フォームのスクリーンショットを貼る）

レビューとマージ

レビュアー（チームメンバー）はコードを確認し、コメントを残したり「Approve（承認）」を行います。承認後、PRをマージしてfeatureブランチを削除します。

# マージ後、ローカルのブランチを整理する
git switch main
git pull origin main               # マージ後の最新mainを取得
git branch -d feature/add-contact-form  # ローカルブランチを削除

GitHub Flowの解説

GitHub Flowは、GitHubが推奨するシンプルなブランチ戦略です。

GitHub Flowの基本ルール：

main ブランチは常にデプロイ可能な状態を保つ
作業は必ず新しいブランチで行う
こまめにコミットして、リモートにプッシュする
フィードバックが欲しいときや完成したらPRを作成する
PRがレビューを通過したら main にマージする
main にマージしたらすぐにデプロイする

実際の作業フロー：

# Step 1: mainを最新にする
git switch main
git pull origin main

# Step 2: 意味のある名前でブランチを作成
git switch -c feature/user-authentication

# Step 3: 作業してコミット（小さい単位でこまめに）
git add .
git commit -m "feat: ログインフォームのUIを実装"

git add .
git commit -m "feat: JWT認証のロジックを追加"

git add .
git commit -m "test: ログイン機能のテストを追加"

# Step 4: リモートにプッシュ
git push -u origin feature/user-authentication

# Step 5: GitHubでPRを作成してレビュー依頼

# Step 6: レビュー通過後、mainにマージ（GitHub上の操作）

# Step 7: ローカルを整理
git switch main
git pull origin main
git branch -d feature/user-authentication

個人開発でもブランチを使うメリット

「一人で開発しているからブランチは不要」と思う方も多いですが、個人開発でもブランチを使うメリットは十分あります。

実験的な変更を安全に試せる： 新しいライブラリやデザイン変更を試したいとき、ブランチを切ることで「やっぱりやめよう」と思ったときにmainに影響なく元に戻せます。

コミット履歴がきれいになる： 機能単位でブランチを作ることで、どの変更がどの機能のためのものかが明確になります。

PRのレビューが自分でも使える： GitHubでPRを作ってマージする習慣をつけると、コミット履歴がまとまりやすく、過去の変更を見返しやすくなります。

ブランチ命名規則の例：

feature/機能名    → 新機能追加
fix/バグ内容      → バグ修正
refactor/対象     → リファクタリング
docs/対象         → ドキュメント更新
chore/内容        → 雑務（設定変更、依存パッケージ更新など）

よく使うGitコマンドチートシート

# ブランチ操作
git branch                        # ブランチ一覧
git switch -c ブランチ名           # 作成して切り替え
git switch ブランチ名              # 切り替え
git branch -d ブランチ名           # 削除（マージ済み）

# 変更の確認
git status                        # 変更されたファイルを確認
git diff                          # 変更内容を差分で確認
git log --oneline                 # コミット履歴をシンプルに表示
git log --oneline --graph --all   # ブランチの分岐をグラフ表示

# マージ
git merge ブランチ名               # 現在のブランチに指定ブランチをマージ
git merge --abort                 # マージを中止して元に戻す

# リモート操作
git push -u origin ブランチ名     # 初回プッシュ（上流を設定）
git push                          # 2回目以降のプッシュ
git pull                          # リモートの変更を取得してマージ
git fetch                         # リモートの変更を取得するだけ（マージしない）

改訂2版わかばちゃんと学ぶ Git使い方入門

マンガ形式でGitの基礎からブランチ、プルリクエストまでを楽しく学べる入門書。コマンドラインとGitHubの使い方が初心者でも直感的に理解できます。

¥2,178 Amazonで見る

※ アフィリエイトリンクを含みます

Udemy — 【世界で18万人が受講】Git：はじめてのGitとGitHub

GitとGitHubの基礎からブランチ・マージ・プルリクエストまで、動画で体系的に学べる日本語入門講座。実際の操作画面を見ながら学べるので初心者でも安心です。

¥1,500〜 Udemyで見る