ブランチ

ブランチとは？

ブランチ（branch）は、コミット履歴の「分岐」です。 メインのコードに影響を与えずに、新しい機能の開発やバグ修正を独立して進められます。 完成したら、メインのブランチに統合（マージ）します。

  main:       A ── B ── C ── D ── E ── F（マージコミット）
                          \             /
  feature:                 C1 ── C2 ──

  ※ main から分岐して feature ブランチで開発
  ※ 完成したら main にマージ

ブランチを使うことで、「本番コードを壊さずに開発できる」「複数人が同時に別機能を開発できる」 という大きなメリットがあります。

ブランチの作成と切り替え

# ブランチの一覧を表示（* が現在のブランチ）
$ git branch
* main
  feature/login

# 新しいブランチを作成
$ git branch feature/header

# ブランチを切り替え（switch が推奨）
$ git switch feature/header

# 作成と切り替えを同時に行う
$ git switch -c feature/header

# 古い書き方（checkout でも可能）
$ git checkout feature/header
$ git checkout -b feature/header    # 作成 + 切り替え

ブランチの削除

マージ完了後の不要なブランチは削除してリポジトリを整理しましょう。

# マージ済みのブランチを削除
$ git branch -d feature/header

# マージされていないブランチを強制削除
$ git branch -D feature/experimental

# リモートのブランチを削除
$ git push origin --delete feature/header

git merge - ブランチの統合

あるブランチの変更を別のブランチに取り込みます。 通常は main ブランチに 機能ブランチをマージします。

# まず main ブランチに切り替え
$ git switch main

# feature ブランチを main にマージ
$ git merge feature/header

マージの種類

Before:
main:    A ── B
                \
feature:         C ── D

After (fast-forward):
main:    A ── B ── C ── D

Before:
main:    A ── B ── E
                \
feature:         C ── D

After (merge commit):
main:    A ── B ── E ── M
                \       /
feature:         C ── D

マージコンフリクト（競合）

同じファイルの同じ部分が両方のブランチで変更された場合、Gitは自動でマージできず、コンフリクト（競合）が発生します。 手動で解決する必要があります。

# コンフリクトが発生したファイルの中身
<<<<<<< HEAD
<h1>メインブランチの変更</h1>
=======
<h1>featureブランチの変更</h1>
>>>>>>> feature/header

コンフリクトの解決手順：

# 1. コンフリクトしたファイルを編集して正しい内容にする
#    （<<<<<<< ======= >>>>>>> のマーカーをすべて削除）

# 2. 解決したファイルをステージング
$ git add index.html

# 3. マージコミットを作成
$ git commit -m "feature/header をマージ（コンフリクト解消）"

git rebase - 履歴を整理する

rebase は、 ブランチの起点を別のコミットに移動させる操作です。 マージと似ていますが、履歴が直線的になるのが特徴です。

# feature ブランチで作業中に main の最新を取り込む
$ git switch feature/header
$ git rebase main

Before rebase:
main:    A ── B ── E
                \
feature:         C ── D

After rebase:
main:    A ── B ── E
                     \
feature:              C' ── D'

※ C, D が E の後ろに移動（C', D' は新しいコミット）

ブランチ戦略

チームでの開発では、ブランチの使い方にルールを設けることが一般的です。 代表的な戦略を紹介します。

GitHub Flow（シンプル）

小規模チームや継続的デプロイ向け。シンプルで分かりやすい。

main ─────────────────────────────────▶ (常にデプロイ可能)
      \                    /
       feature ── PR ── merge

1. main から feature ブランチを作成
2. 開発・コミット
3. Pull Request を作成
4. レビュー・承認
5. main にマージ → 自動デプロイ

Git Flow（本格的）

リリースサイクルが明確なプロジェクト向け。

main ─────────────────────────▶ (リリース版)
  │
develop ──────────────────────▶ (開発版)
  │      \            /
  │    feature ── merge
  │
  ├── release/1.0 ── merge → main
  │
  └── hotfix ── merge → main + develop

よく使うブランチコマンドまとめ