Part 2: 開発ツール基礎Git
Chapter 11: ブランチ運用
ブランチの作成・マージ・運用戦略
Chapter 11: ブランチ運用
11.1 ブランチとは何か
ブランチとは、開発の流れを枝分かれさせる機能です。
たとえば、Webサービスで「ログイン機能」と「検索機能」を同時に開発したいとします。1本の開発ラインで進めると、ログイン機能が壊れた状態で検索機能を開発することになり、お互いに干渉してしまいます。
ブランチを使えば、メインの開発ラインに影響を与えずに、別の作業空間で新機能を開発できます。
11.2 ブランチの作成と切り替え
ブランチの一覧を確認する
git branch
# * main ← * がついているのが現在いるブランチブランチを作成して切り替える
# ブランチを作成(まだ切り替えない)
git branch feature/login
# ブランチを切り替える
git checkout feature/login
# または、作成と切り替えを同時に行う(おすすめ)
git checkout -b feature/login
# 新しいやり方(Git 2.23以降)
git switch -c feature/login作業してからメインに戻る
# feature/login ブランチで作業
echo "<form>ログイン</form>" > login.html
git add login.html
git commit -m "ログインページを追加"
# main ブランチに戻る
git checkout main
# ls をしても login.html がない!→ブランチが切り替わっているためブランチを切り替えると、作業ディレクトリの中身もブランチの状態に切り替わります。これがブランチの仕組みです。
11.3 マージの基本
開発したブランチをメインのブランチに取り込む操作を**マージ(merge)**といいます。
# main ブランチにいることを確認
git checkout main
# feature/login ブランチをマージ
git merge feature/login
# Updating abc1234..def5678
# Fast-forward
# login.html | 1 +
# 1 file changed, 1 insertion(+)Fast-forward マージ
mainが変わっていない状態でマージすると「Fast-forward」になります。ブランチのコミットがそのまままmainの先端になります。
通常のマージ(Merge commit)
mainに新しいコミットがある場合は「マージコミット」が作られます。
11.4 コンフリクトの解消
コンフリクト(競合)とは、2つのブランチが同じファイルの同じ箇所を異なる内容で変更した場合に発生します。
コンフリクトの例
# コンフリクトが発生すると以下のように表示される
git merge feature/login
# CONFLICT (content): Merge conflict in index.html
# Automatic merge failed; fix conflicts and then commit the result.コンフリクトしたファイルを開くと:
<<<<<<< HEAD(現在のブランチ = main の内容)
<h1>ようこそ!</h1>
=======(ここが境界線)
<h1>こんにちは!</h1>
>>>>>>> feature/login(マージしようとしているブランチの内容)コンフリクトの解消方法
- コンフリクトしているファイルをエディタで開く
<<<<<<<、=======、>>>>>>>の行を含めて、どちらの内容を残すか決めて編集する- ファイルを保存する
git addしてコミットする
# 解消後
git add index.html
git commit -m "コンフリクトを解消: ようこそメッセージを統合"コンフリクトを減らすコツ
- こまめにpullする: 最新のmainを頻繁に取り込む
- 小さなブランチを短期間で: 長期間ブランチを分岐させない
- 担当範囲を明確に: 同じファイルを複数人で同時に変更しない
11.5 ブランチ戦略
チーム開発では、ブランチの使い方のルールを決める「ブランチ戦略」が重要です。代表的な2つの戦略を紹介します。
GitHub Flow
GitHub Flow はシンプルで実用的なブランチ戦略です。小〜中規模のチームに適しています。
GitHub Flow のルール:
mainブランチは常にデプロイ可能な状態を保つ- 新しい作業は必ずブランチを切って行う
- こまめにプッシュして共有する
- Pull Request を使ってレビューしてからマージ
- マージ後すぐにデプロイ
# GitHub Flow の操作例
git checkout main
git pull origin main # 最新を取得
git checkout -b feature/user-profile # ブランチを切る
# ...作業...
git add .
git commit -m "ユーザープロフィールページを追加"
git push origin feature/user-profile # プッシュ
# GitHub で Pull Request を作成
# → レビュー → マージGit Flow
Git Flow はより厳格なブランチ戦略で、大規模プロジェクトやリリーススケジュールが決まっているプロジェクトに向いています。
| ブランチ | 用途 |
|---|---|
main | 本番リリース済みのコード |
develop | 開発中の統合ブランチ |
feature/* | 新機能の開発 |
release/* | リリース準備 |
hotfix/* | 緊急バグ修正 |
どちらを選ぶか
| 条件 | 推奨 |
|---|---|
| 少人数・スタートアップ | GitHub Flow |
| 継続的デプロイ(CD)あり | GitHub Flow |
| リリースサイクルが決まっている | Git Flow |
| 複数バージョンを並行保守 | Git Flow |
初めてのチーム開発では GitHub Flow から始めることをおすすめします。シンプルで覚えやすく、ほとんどの場面で十分機能します。
まとめ
| コマンド | 用途 |
|---|---|
git branch | ブランチ一覧 |
git checkout -b <名前> | ブランチを作成して切り替え |
git checkout <名前> | ブランチを切り替え |
git merge <ブランチ名> | ブランチをマージ |
git branch -d <名前> | ブランチを削除 |
次のステップ: GitHub 入門 でリモートリポジトリを使ったチーム開発を学びます。