git branchを今さら人に聞けないエンジニアへ：ブランチとは何か、なぜ現場で必須なのか
正直に言うと、ブランチって「便利そう」まではわかるけど、実戦で使ってないと永遠に“ふわっとした概念”のままです。
しかも、チームではGit操作自体はやってるから、余計に「今さら聞けない…」になりがち。
このページは、git branchをほぼ使ったことがない“知ったかぶりエンジニア”が、現場で困らないところまで一気に追いつくための実用記事です。
git branch（ブランチ）とは？一言でいうと
ブランチとは、同じリポジトリの中で、別の作業線（履歴の分岐）を作る仕組みです。
もっと噛み砕くと、「本番に影響しない別世界を作って、安心して作業できる」のがブランチです。
ブランチが無い世界の地獄（あるある）
- main（またはmaster）で直接作業して、途中の未完成コミットが混ざる
- 「とりあえず動く」状態を保てず、他メンバーの作業を止める
- 緊急修正を入れたいのに、開発中の変更が邪魔で切り戻しが面倒
- 誰の変更がどれか追いにくい（レビュー不能・責任境界が曖昧）
ブランチのリアルなメリット（現場で効くやつだけ）
メリット1：未完成の作業をmainに混ぜずに済む（事故率が激減）
ブランチ運用の本質はここです。mainは常に動く状態に保ち、作業はブランチで進めます。
「mainが壊れて全員の開発が止まる」を避けられます。
メリット2：レビューが成立する（差分が見える）
Pull Request（PR）/ Merge Request（MR）は、基本的にブランチ差分が前提です。
ブランチがあると、変更の意図・影響範囲・戻しやすさが一気に改善します。
メリット3：緊急対応（hotfix）が刺さる
本番で障害 → すぐ直したい。
でもmainに開発途中の大きな改修が入っていると、リリースできません。
ブランチ運用なら、本番と同じ地点からhotfixブランチを作って、最小修正だけを安全に出すことができます。
メリット4：「並行作業」が当たり前にできる
- Aさん：新機能
- Bさん：バグ修正
- Cさん：リファクタ
全員が別ブランチで進め、レビューして順にmainへ。
これができると、チーム開発が“ワークフロー”になります。
ブランチのリアルなデメリット（ここを知らないと嫌いになる）
デメリット1：マージが怖い（コンフリクト）
ブランチを切るほど、どこかで統合が必要になります。
同じ行や同じファイルを複数人が触ると、コンフリクト（競合）が起きます。
ただし、これは「ブランチが悪い」ではなく、統合の頻度が低い / ブランチが長生きしすぎが主原因です。
デメリット2：運用が雑だとブランチが墓場になる
- ブランチが増えすぎて何が何だかわからない
- 放置ブランチだらけ（どれが最新？）
- 巨大PRでレビュー不能
対策はシンプルで、ブランチ命名・短命運用・小さめPRを守るだけで激減します。
デメリット3：rebase/force push周りで事故る
慣れるまでは、共有ブランチに対するrebaseやforce pushが事故ポイントです。
ルールさえ決めれば回避できます（後半にまとめます）。
まず覚えるべき前提：main（本線）と作業ブランチの関係
- main：安定しているべき（デプロイ対象になりがち）
- featureブランチ：新機能・改修
- fixブランチ：バグ修正
- hotfixブランチ：本番緊急修正（最短で出す）
今日から使える：ブランチ運用の最小セット（これだけで8割勝てる）
運用ルール（ミニマム）
- mainに直接コミットしない（原則）
- 作業は必ずブランチを切る
- PR/MRでレビューしてmainへ取り込む
- 取り込み後はブランチを消す（墓場化防止）
- ブランチは短命（理想：数時間〜数日）
ブランチ名のおすすめ（迷ったらこれ）
- feature/xxx：新機能（例：feature/genba-search）
- fix/xxx：通常のバグ修正（例：fix/login-redirect）
- hotfix/xxx：本番緊急修正（例：hotfix/payment-500）
- chore/xxx：雑務（依存更新、設定など）（例：chore/deps-update）
具体的な操作方法：ブランチ作業の基本フロー（コピペでOK）
0) まずは最新のmainを手元に持ってくる
git switch main
git pull
※ 古いgitだと git switch が無いことがあります。その場合は git checkout を使います（後述）。
1) ブランチを作って移動する
# 新しいブランチを作って、そのまま移動
git switch -c feature/genba-search