枝分かれの作法｜特別編チームで使うブランチ戦略とPR運用

著者: 管理者 / 2025-08-25 (更新: 2025-08-25)

先生……。個人開発のときは `git push` で済んでいましたけれど、チームでは「Pull Request」を作るのが礼儀、と聞きましたの。
でも、なぜそんな回り道をする必要があるのかしら？

良い質問ですね。Pull Request、通称 PR は「コードをみんなで確認してから取り込む仕組み」です。
“回り道”ではなく、“交通ルール”のようなものなのです。

git switch -c feature/login

git add .
git commit -m "feat: add login page"
git push -u origin feature/login

GitHubで Pull Request を作成
- base（取り込み先）: main
- compare（作業ブランチ）: feature/login
レビュー & 修正
- コメントで指摘があれば修正し、再度 push
マージ
- Merge commit
- Squash and merge
- Rebase and merge

まあ！`push` してもすぐには main に入らないのですのね。
まずは「ここを取り込んで良いですか？」と皆さまにお願いする場が PR なのですわね🌸

その通りです。PRは「相談の場」であり、「レビューの場」でもあります。

Merge commit
- そのまま合流。履歴は分岐の形を保つ。
- チームで「どんな枝があったか」を残したいときに便利。
Squash and merge
- 複数のコミットをまとめて1つに。
- 履歴がすっきりするが、細かい途中経過は消える。
Rebase and merge
- 作業ブランチを main の末尾に積み直してからマージ。
- 履歴が直線的になるが、共有後に rebase するのは慎重さが必要。

まあ！`Squash and merge` は“おまとめセール”のようですわね🛍️

ふふ、その比喩は面白いですね。はい、まとめ買いして領収書は1枚――そんな感覚です。
一方で「細かい作業ログを残したいとき」は `Merge commit` が適しています。

## What
- ログインページを追加しました
- 入力フォームとバリデーションを実装

## Why
- ユーザー認証が必要になったため

なるほど……PRは単なる技術的な操作ではなく、チームの会話の場でもあるのですのね💡
レビューを受けるのが少し緊張いたしますけれど、マナーを守れば安心ですわ😊

そうです。PRはコードの安全確認だけでなく、知識を共有する場でもあります。
レビューを通じて「この書き方のほうが良い」という学びが広がるのです。

GitHub Flow（シンプル）
- main 一本
- 機能ごとに短期の feature/* ブランチを作って PR
- 小規模チームに向いている
Git Flow（大規模）
- main（本番用）、develop（開発用）、feature/*、release/*、hotfix/*
- 大規模プロジェクトやリリース管理が重要な場合に向いている
Trunk-Based Development
- 常に main に近い状態を保ち、短期間でマージする
- CI/CD（自動テスト＆デプロイ）と相性が良い