ブランチ戦略入門：GitHub Flow・git-flow・trunk-based development

# 1. main から feature ブランチを作成
git checkout main
git pull origin main
git checkout -b feature/add-login

# 2. 変更してコミット
echo "# Login page" > login.md
git add login.md
git commit -m "feat: ログインページを追加"

# 3. リモートへプッシュ（プルリクエストはGitHub UI で作成）
git push -u origin feature/add-login

GitHub Flow のポイント：

• main は常にデプロイ可能な状態を維持する
• ブランチ名は作業内容が分かるように命名する（例: feature/add-login, fix/typo-in-readme）
• プッシュしたらすぐにプルリクエストを作成してレビューを依頼する
• レビュー通過後、main にマージしてすぐにデプロイする

v1.2.0 のリリース準備：

# develop から release ブランチを作成
git checkout develop
git pull origin develop
git checkout -b release/1.2.0

# バージョン番号を更新してコミット
# （package.json や VERSION ファイルなどを編集）
git add .
git commit -m "chore: バージョンを1.2.0に更新"

# テスト・バグ修正後、main と develop 両方にマージ
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release v1.2.0"

git checkout develop
git merge --no-ff release/1.2.0

# release ブランチを削除
git branch -d release/1.2.0

--no-ff オプションを使うことで、マージコミットを明示的に作成し、ブランチの存在を履歴に残します。

フィーチャーフラグ（Feature Flag）を使う方法が一般的です。

# Python の例
import os

FEATURE_NEW_DASHBOARD = os.environ.get("FEATURE_NEW_DASHBOARD", "false") == "true"

if FEATURE_NEW_DASHBOARD:
    # 新しいダッシュボードを表示（開発中）
    render_new_dashboard()
else:
    # 既存のダッシュボードを表示
    render_old_dashboard()

# 本番環境ではフラグをオフにしたまま main にマージ可能
git checkout -b feat/new-dashboard
# ... 実装 ...
git checkout main
git merge feat/new-dashboard  # フラグがオフなので本番に影響なし
git push origin main

trunk-based development のポイント：

• ブランチは最大1〜2日で main にマージする
• 未完成の機能はフィーチャーフラグで隠す
• CI が常にグリーンな状態を保つ
• 小さなコミットを頻繁にマージすることでコンフリクトを最小化する

方法1: merge（履歴を保持する）

git checkout feature/big-refactor
git fetch origin
git merge origin/main

# マージコミットが作られる
# 例: Merge branch 'main' into feature/big-refactor

メリット：

• main のどのコミットで同期したかが履歴に残る
• チームで共有しているブランチに安全（force push 不要）

方法2: rebase（履歴をきれいに保つ）

git checkout feature/big-refactor
git fetch origin
git rebase origin/main

# feature ブランチのコミットが main の先頭に積み直される
# ※ 共有ブランチの場合は force push が必要になるため注意

メリット：

• コミット履歴が直線的でわかりやすくなる
• git log --oneline がすっきりする

どちらを選ぶか：

• 個人の feature ブランチ → rebase 推奨（きれいな履歴）
• チームで共有しているブランチ → merge 推奨（安全性優先）

よく使われるプレフィックス：

• feature/ または feat/: 新機能
• fix/ または bugfix/: バグ修正
• hotfix/: 本番の緊急修正
• chore/: ビルド・依存関係・設定の変更
• docs/: ドキュメントのみの変更
• refactor/: リファクタリング
• release/: リリース準備
• test/: テストの追加・修正

チームで .github/BRANCH_NAMING.md などにルールを文書化しておくと、全員が迷わず一貫したブランチ名をつけられます。