チーム開発では「コードを書く」だけでなく、「変更を安全に共有する」ことが同じくらい重要です。
Gitのコミットやブランチ運用、Pull Request（PR）の出し方が雑だと、レビュー負荷が上がったり、意図しない差分が混ざったりして、リリースや修正が遅れがちになります。
この記事では、実際にチーム開発をしてみて**「これは気をつけるべきだった」**と感じたGit/PR運用のポイントを、具体例付きでまとめます。
特に、次のような人を想定しています。
- PRを出しているけど、レビューが通りにくい / 指摘が多い
- 差分が大きくなってコンフリクトが頻発する
- コミットやブランチ名、PR説明が毎回ブレる
- 「チームに優しい変更の出し方」を身につけたい
1. ブランチ運用：名前と粒度を揃える
- ブランチ名は 目的が一目でわかる ようにする
例：fix:toc-anchor-bug / feat:blog-pagination / chore:update-deps
- 1ブランチ = 1目的（複数の話題を混ぜない）
→ レビューもしやすく、差し戻しもしやすい
実際の学び
「ついで修正」を入れると、レビューコメントが増えるし、リリース時に戻しづらい。
2. コミット：メッセージは“何をしたか”より“何のためか”
- 良い例：fix: preserve page param when navigating back
- 微妙例：fix bug / update（情報が少なすぎる）
おすすめは、次のどれかに寄せると安定する：
- 何を直したか（fix）
- 何を追加したか（feat）
- 何を整理したか（refactor/chore）
ポイント
レビューの時に「コミットログだけで変更意図が追える」と、チームの時間が節約される。
3. PRの差分：小さく切る（レビューコストを下げる）
- PRはできるだけ“小さく”
目安：ファイル数や差分行数が多いほどレビュー難易度が上がる
- UI変更 + ロジック変更 + 型修正…を一緒にすると、レビュアーが迷子になる
→ 可能なら「見た目」「挙動」「型/リファクタ」を分ける
実際の学び
大きいPRほど「何が本質の変更か」が伝わらず、指摘が増える。
4. PR説明（Description）：レビュアーの視点で書く
PR説明に最低限入れると強いテンプレ：
- 背景 / 課題：なぜやるのか
- 対応内容：何をどう変えたか（箇条書き）
- 確認方法：どこを見ればOKか（手順 or 画面）
- 影響範囲：影響あるページ/機能
- スクショ：UIならBefore/Afterがあると神
例（貼って使える形）：
- 背景：記事詳細でTOCクリックしてもスクロールしない
- 対応：本文のh1/h2にidを付与したHTMLを表示側に渡すよう修正
- 確認：記事詳細でTOCをクリック→該当見出しへスクロールすること
5. “余計な差分”を出さない（自分が損する）
- package-lock.json やフォーマット差分が必要以上に変わっていないか
- 生成ファイル・不要なログ・関係ない改行が混ざっていないか
コツ
- PR前に git diff / git status で「説明できない差分」がない状態にする
6. コンフリクトを減らす：早めに最新を取り込む
- 長期間ブランチを放置すると、マージ時に地獄になりやすい
- こまめに main（または開発ブランチ）を取り込む
例：rebase or merge はチームの流儀に合わせる
意識すること
「コンフリクトは避ける」より「小さいうちに片付ける」。
まとめ
Git/PR運用は、技術というより「チームのためのコミュニケーション」です。
ブランチ名・コミット・PR説明・差分の粒度を揃えるだけでも、レビューがスムーズになり、手戻りが減って開発スピードが上がります。
最初は面倒に感じますが、慣れるほど「自分が楽になる」運用なので、まずは PRを小さくする / 説明を丁寧にする ところから始めるのがおすすめです。