初心者チームの Git 運用ルール（GitHub Desktop 版）

— main / develop / feature ブランチ戦略 —

0. 目的と前提

  • 目的：安全に並行開発し、レビュー（PR）経由で高品質に統合する。
  • 前提：GitHub アカウント、GitHub Desktop、VS Code を利用。

1. ブランチの役割

  • main
    • 常にリリース可能（デプロイ対象）。
    • 直接コミット禁止（PR 経由のみ）。
  • develop
    • 次のリリースに向けた統合ブランチ。
    • 複数の feature を集約して動作確認。
  • feature/*
    • 個別機能・修正用の作業ブランチ。
    • feature/add-login、feature/refactor-user-service など分かりやすい命名。

小規模チームなら main + feature/* でも可。混乱し始めたら develop を導入。

2. 命名規則

  • ブランチ：feature/<目的-要約> / fix/<不具合-要約> / hotfix/<緊急修正>
    • 例）feature/add-login, fix/header-typo, hotfix/critical-npe
  • コミットメッセージ（Conventional Commits 推奨）
    • 形式：<type>: <短い説明>（必要に応じて本文・フッタ）
    • feat: 機能追加 / fix: バグ修正 / docs: 文書 / refactor: リファクタ / test: テスト / chore: 雑務
    • 例）feat: ユーザー登録フォームを追加

3. 1日の基本フロー（各メンバー）

  1. 作業前に最新化
    • GitHub Desktop：Fetch origin → Pull（対象：develop もしくは自分の feature）
  2. ブランチ作成
    • Branch → New Branch（元は develop が基本）
  3. 実装 → VS Code で編集
  4. コミット
    • GitHub Desktop：変更を確認 → メッセージ → Commit to <feature>
  5. プッシュ
    • Push origin
  6. PR 作成
    • 右上 Create Pull Request → GitHub で PR を作成（後述のテンプレに沿う）
  7. レビュー対応 → マージ
    • develop へマージ（原則 Squash and merge）
  8. 次作業の前に再度 Pull（衝突を小さく保つ）

4. プルリクエスト（PR）運用

  • どこに出す？
    • 通常：feature → develop
    • リリース直前のホットフィックス：hotfix → main（レビュー後に develop へも反映）
  • PR の大きさ：小さく速く（レビュー 15–20 分で読める粒度）
  • レビュー基準（最低限）
    • ビルド/テストが通る
    • 命名・責務が明確、差分が読みやすい
    • 仕様・UI の影響が記載されている
  • マージ方式：Squash and merge 推奨
    • main / develop の履歴を綺麗に保つ
  • PR テンプレ（例）
## 目的
ログイン機能の追加

## 変更点
- /login 画面を新規追加
- 認証APIクライアントの導入

## 動作確認
- ユーザー作成 → ログイン → トップへ遷移

## 影響範囲
- ルーティング/ヘッダーのリンク

## 備考
- ユニットテストは別PRで追加予定

5. リリースとタグ

  • develop → main をマージしたら、タグを打ってリリース管理：
    • 例）v1.2.0（機能追加）、v1.2.1（バグ修正）
  • GitHub Releases に変更点（CHANGELOG）を記録。

6. コンフリクトの基本方針

  • 発生を減らす：こまめに Pull、PR を小さく、作業範囲を分割。
  • 発生したら：
    • GitHub Desktop の Resolve conflicts で比較
    • Accept Current/Incoming/Both or VS Code で手動編集
    • Mark as resolved → Commit merge
  • 迷ったら相談して判断（仕様解釈が入る箇所は独断で決めない）

7. ルール（Do / Don’t）

Do

  • 作業開始前とプッシュ前に Pull
  • 1 機能 1 ブランチ・小さな PR
  • 目的が分かるコミットメッセージ
  • 画面/仕様に影響があれば PR 説明にスクショや補足

Don’t

  • main へ直接 push
  • 1 つのブランチで複数タスクを詰め込む
  • 大型 PR（レビュー不能）
  • 議論不要の小修正をまとめず放置（小まめに PR）

8. 役割分担（小規模チーム例）

  • メンテナ（1 名）：ブランチ保護設定、リリース、レビュー基準の維持
  • レビュア（2 名～）：PR レビュー、設計・品質の指摘
  • 実装担当：feature 作業、テスト、PR 作成

GitHub の「Branch protection rules」で以下を設定：

  • main（必須）・develop（推奨）を保護
  • 直 push 禁止、レビュー必須、ステータスチェック（CI）必須 など

9. 失敗しにくい運用 Tips

  • Squash merge で履歴をスリムに
  • ドラフト PRを早めに作って、方向性レビューを受ける
  • タスク分割：UI・API・テストを別 PR に分ける
  • 共通コードは feature を切る前に develop に取り込み、各自が Pull してから作業開始
  • レビューの SLA（例：24h 以内に一次反応）をチームで合意

10. GitHub Desktop 手順サマリ（よく使う操作）

  • 最新化：Fetch origin → Pull origin
  • ブランチ作成：Branch → New Branch
  • コミット：変更を選択 → メッセージ → Commit to <feature>
  • プッシュ：Push origin
  • PR 作成：右上 Create Pull Request → GitHub で説明記入 → 作成
  • マージ後：main/develop を Pull → 不要ブランチを Delete で掃除

付録：最初の 1 週間の動き（サンプル運用）

  • Day 1：リポジトリ準備、develop 作成、保護設定、テンプレ（PR/ISSUE）導入
  • Day 2–3：各自 feature/* 着手、ドラフト PR で方向性レビュー
  • Day 4：小 PR を順次レビュー＆Squash マージ → develop に集約
  • Day 5：develop の動作確認 → main へマージ＆タグ付け → デプロイ

まとめ

  • main：常に出せる状態。PR 経由のみ。
  • develop：次版の統合。基本は feature → develop マージ。
  • feature/*：1 機能 1 ブランチ、小 PR、こまめに Pull。
  • GitHub Desktop を中心に、“小さく速く・安全に” を徹底。
訪問数 5 回, 今日の訪問数 1回

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

Posted by hidepon