GitHub Desktop を使った チームでのレビュー＆PR運用ベストプラクティス

0. 目的

  • 変更の品質を上げる（バグ流入を減らす）
  • レビュー負荷を平準化して継続可能にする
  • 履歴を読みやすく保ち、将来の保守コストを下げる

前提：リポジトリ管理・コミット／プッシュは GitHub Desktop、編集は VS Code。

1. PR の基本方針

  • 小さく速く：1PR の目安は ~300 行差分 / 15–20分で読める 規模
  • 1PR = 1目的（リファクタと機能追加を混在させない）
  • Draft PR 早期作成：方向性レビューを早く受けて手戻りを減らす
  • Squash & merge 推奨：main / develop の履歴をきれいに保つ
  • レビュー SLA：一次反応は 24h 以内（チーム合意）

2. ブランチ運用（おさらい）

  • main：常にリリース可能。直 push 禁止（PR 経由のみ）
  • develop：次版の統合（必要なチームのみ運用）
  • feature/*：作業用。例）feature/add-login
  • 着手前 Pull → feature 作成 → コミット／プッシュ → PR

GitHub Desktop：

  • Fetch origin → Pull で最新化
  • Branch → New Branch で作業ブランチ作成
  • 右上 Create Pull Request で PR 作成（GitHub が開く）

3. PR 作成時のテンプレ（コピペ可）

.github/pull_request_template.md に保存推奨。

## 目的
（このPRで達成したいこと。背景・課題）

## 変更点
- 箇条書きで

## 動作確認
- 手順（再現手順/期待結果）
- スクリーンショット/ログ（必要に応じて）

## 影響範囲
- 影響するモジュール/画面/設定

## 確認項目（作者）
- [ ] ビルド/テスト通過
- [ ] Lint/Formatter 通過
- [ ] セキュリティに関わる差分なし/対策済み
- [ ] ドキュメント更新（必要なら）

## 備考
（レビュー観点の誘導、フォローアップPR予定など）

4. レビュアーのチェックリスト

設計/仕様

  • 仕様要件を満たしているか、仕様の解釈にズレはないか
  • 責務の分離、命名・可読性、変更範囲の妥当性

品質

  • 既存機能を壊していないか（回帰）
  • 例外・エラーハンドリング、境界ケース
  • パフォーマンス/セキュリティ影響

メンテナンス

  • テストの有無（単体/簡易でも可）
  • ドキュメント/コメントは十分か
  • 将来の拡張に耐えられる設計か

結果

  • 変更要求（Request changes）／承認（Approve）／コメントのみ（Comment）

5. コメントの作法（生産的なレビュー）

  • 主観→理由→代替案 の順で書く例）「読みづらい → X と Y が同一責務に見えるため → Z に分割はどうでしょう」
  • Nit（好み）と Must（必須修正）を明確に
  • 承認後の小指摘は フォローアップ Issue/PR に回す

6. マージルール

  • 原則 Squash & merge
    • main / develop の履歴を要約コミットで保持
    • タイトルは「スコープ: 要約」（例：feat(auth): add login）
  • コンフリクト発生時
    • GitHub Desktop の Resolve conflicts → Accept Current/Incoming/Both
    • 必要なら VS Code で手動編集 → Mark as resolved → Commit merge
  • マージ後
    • 不要な feature ブランチを削除
    • 最新を Pull しローカルを同期

7. ラベル運用例（コピペ導入）

  • 種別：type:feat type:fix type:docs type:refactor
  • 重要度：prio:high prio:normal prio:low
  • 範囲：area:frontend area:backend area:infra
  • 状態：status:draft status:review-needed status:changes-requested

ラベルで レビュー優先順位 を視覚化。

8. CODEOWNERS / Branch 保護

  • CODEOWNERS で領域ごとの標準レビュアーを自動アサイン
# /src/auth 配下は Auth チームが担当
/src/auth/*  @org/auth-team
  • Branch protection rules（GitHub 設定）
    • main（推奨：developも）を保護
    • 直 push 禁止
    • 最低1–2名のレビュー必須
    • ステータスチェック必須（CI 合格がマージ条件）

9. CI/チェック（将来導入前提の最小構成）

  • Lint/Format（例：ESLint / Prettier、dotnet format など）
  • Unit Test（スモールでも OK）
  • Build（本番と同等のビルドを最低限）

PR に緑のチェックが付く状態を「合格」と定義。

10. GitHub Desktop の運用 Tips

  • 「History」タブで過去のコミット要約を確認し、PR 単位の差分把握に慣れる
  • コンフリクト時は 差分プレビューで “どちらの意図が正しいか” を判断材料に
  • Revert で安全に巻き戻す（ただし main へ直接は不可。PR で）

11. 失敗しにくい運用の型

  • 毎朝 Pull → 小粒で Draft PR
  • 昼までに1レビュー（SLA 24h の前倒し運用）
  • 夕方に Squash マージ（まとめてではなく都度）
  • 大型変更は 設計PR（ドキュメントだけの PR）を先に出して合意

12. 付録：PR 例タイトル & コミット文（Conventional Commits）

  • タイトル：feat(auth): add login form and validation
  • Squash コミット本文：
- add /login route and page
- implement client-side validation
- update auth API client

13. 著者チェックリスト（配布用）

  • 目的と背景を PR に記述した
  • 変更点・動作確認手順を書いた
  • 影響範囲を明記した
  • スクショ/ログ（必要な場合）を添付した
  • Lint/Formatter/Build/Tests が通った
  • PR を小さく保ち、フォローアップは分割した

まとめ

  • 小さく速く、PR は1目的
  • Draft で早く見せる → SLA 24h
  • Squash & merge とブランチ保護で履歴を健全に
  • GitHub Desktop を中心に、レビューと品質の型を「チームの習慣」に落とし込む
訪問数 6 回, 今日の訪問数 1回

バージョン管理,便利機能

Posted by hidepon