Gitブランチ運用の基本 ― feature/main運用とPRの読み方

Git記事でリポジトリ・コミット・ブランチ・リモートの基本用語を押さえたら、次にぶつかるのが実務の壁です。AIやチームメイトが「feature/login-pageというブランチでPRを作りました」と言ってきたとき、その言葉の意味を全部説明できるでしょうか。この記事では、ブランチを分ける理由からPR(プルリクエスト)の読み方まで、実務でそのまま使える単位で整理します。

なぜmainで直接作業してはいけないのか

「1人で開発しているのだから、ブランチなんて要らないのでは」と思うかもしれません。実際にはブランチは人数に関係なく、「試している最中の変更」と「動作確認済みの本体」を分けるための仕組みです。

# 現在のブランチを確認する(気づかずmainで作業していないか、まずこれで確認する癖をつける)
git branch --show-current

# mainから分岐して作業用ブランチを作る(Git 2.23以降の新しいコマンド)
git switch -c feature/login-page

🎯 読み解きポイント：mainは「装備中」、featureブランチは「試着室」

ハクスラゲームでたとえると、mainブランチは今まさに戦闘で使っている装備一式です。新しい武器(コードの変更)を試したいとき、いきなり戦闘中の装備を外すのは危険です。featureブランチは試着室のようなもので、そこで新しい武器を試し、問題なければ改めて本体(main)に反映します。試着室で失敗しても、戦闘中の装備には何の影響もありません。

ブランチ名のfeature/xxxには意味がある

AIが作るブランチ名を「なんか長い英語」と読み飛ばしていないでしょうか。実はこの命名にはGit自体が強制するルールはありませんが、多くのチームが同じ慣習に従っており、プレフィックスを見るだけでそのブランチの目的が分かるようになっています。

# 新機能を作るブランチ: feature/ プレフィックス
git switch -c feature/login-page

# バグ修正のブランチ: fix/ または bugfix/ プレフィックス
git switch -c fix/header-overlap-bug

🎯 読み解きポイント：プレフィックスは「アイテム分類ラベル」

ハクスラゲームの倉庫でアイテムを「武器」「防具」「素材」のタグで分類しておくと、後から探しやすくなります。feature/やfix/はブランチの倉庫タグのようなもので、一覧を見ただけで「これは新機能」「これは修理(バグ修正)」と判別できます。AIが作ったブランチ名がこの形式に沿っていなければ、目的を一言確認する価値があります。

PR(プルリクエスト)とは何を確認する場所か

「PRはとりあえず承認ボタンを押す場所」だと思っていないでしょうか。実際にはPRは、featureブランチの変更をmainに取り込む前に、変更内容を議論・確認するための場です。GitHubのPR画面には主に3つの見るべき場所があります。

PR画面の主なタブ
├─ Conversation … 変更の説明・議論のやり取り
├─ Commits      … このブランチでの変更履歴(コミット単位)
└─ Files changed … 実際の差分(diff)。レビューの中心はここ

🎯 読み解きポイント：レビューの返答は「Comment/Approve/Request changes」の3択

PRのレビューは、単なる合否判定ではなく3種類の意思表示です。Comment(合否を出さず感想だけ伝える)、Approve(この内容でマージしてよい)、Request changes(ここを直してから出し直してほしい)。AIが生成したコードのPRであっても、この3択のどれを選ぶかを意識するだけで、レビューが「なんとなく見て終わり」から「明確な意思表示」に変わります。

mainへの3つの合流方法：fast-forward・マージコミット・squash

「マージなんて全部同じ処理でしょう」と思いがちですが、実はmainへの取り込み方には3つの方式があり、履歴の残り方がまったく変わります。

# ①fast-forward: mainが分岐後に進んでいなければ、
#   マージコミットを作らずポインタを進めるだけ
git merge --ff-only feature/login-page

# ②マージコミット: 分岐した事実を履歴に残す(3-way merge、双方の変更点を1つに統合する方式)
git merge --no-ff feature/login-page

# ③squash: featureブランチの全コミットを1つにまとめてから取り込む
git merge --squash feature/login-page

🎯 読み解きポイント：まっすぐ合流・合流地点に看板・荷物をまとめて1箱

fast-forwardは、脇道(featureブランチ)が本道(main)に何も分岐せず合流できる状態で、看板も立てずにそのまま道をまっすぐ伸ばすイメージです。マージコミット(--no-ff)は、脇道から合流したという事実を示す看板を必ず立てる方式です。squashは、脇道で拾った複数の荷物(コミット)をいったん1つの箱にまとめてから本道に持ち込む方式で、本道の履歴はコミット1つ分だけシンプルになります。オープンソースプロジェクトではmain履歴を綺麗に保てるsquashが好まれる場面が多いです。

よくあるはまりポイント：気づかずmainで作業してpushしてしまう事故

実務で意外と起きるのが、featureブランチを作ったつもりで、実は切り替え忘れてmainのまま作業し、そのままpushしてしまう事故です。GitHub側でmainブランチに直接pushできないよう保護(ブランチ保護、Branch Protection)を設定していれば弾かれますが、設定していないリポジトリでは気づかないまま本番の履歴を汚してしまいます。作業を始める前にgit branch --show-currentで現在地を確認する癖をつけておくと、この事故はほぼ防げます。

あわせて知っておきたい用語

ブランチ保護(Branch Protection): 特定のブランチ(主にmain)への直接pushやレビュー無しのマージを禁止する設定。GitHub/GitLabなどのリポジトリ管理画面から設定する
fast-forward: 分岐先のブランチが分岐元より単純に進んでいるだけの状態。マージコミットを作らずポインタを進めるだけで取り込める

💡 ワンポイントアドバイス：作業前の合言葉は「今どのブランチ？」

AIに何か作業を頼む前、あるいは自分で作業を始める前に、まずgit branch --show-currentで現在のブランチ名を確認する習慣をつけてください。これだけで「気づいたらmainで作業していた」事故のほとんどを未然に防げます。Git記事で紹介したコンフリクトの多くも、実はブランチの切り替え忘れが遠因になっているケースが少なくありません。

ブランチとPRの基本が分かったら、Git記事でコミットやコンフリクトの基礎を、Claude Codeの記事でAIエージェントが実際にどうコマンドを実行するかを確認してみてください。