GitHubの運用ルール（自分用にまとめたもの）

※レビューのやり方をどうしたら良いのかは要検討
現状だとブランチをローカルに落として検証するのが一番良さそう。（もっと良いやり方はありそうだけど）
個人開発でもこのルールをなるべく適用していきたい

概要

本ドキュメントは、小規模チーム（2〜3 人）向けの Git ワークフロー管理ルールを定めたものです。
カスタマイズされた GitHub Flow を採用し、効率的な開発とコード品質の維持を目指します。

---

ブランチ戦略

ブランチ構成

ブランチ名	役割	保護設定
master	本番環境にリリースされているコード	✅ 直接 Push 禁止
develop	最新の開発コード。レビュー完了後のコードが集約される	⚠️ Pull Request 経由での更新推奨
feature/XXX	新規機能開発・改修・バグ修正用の作業ブランチ	-

ブランチ命名規則

作業ブランチは以下の命名規則に従ってください。

feature/[作業内容を表す短い説明]

命名例:

• feature/user-login
• feature/fix-payment-bug
• feature/update-profile-ui
• feature/add-search-function

ポイント:

• 英小文字とハイフン（-）を使用
• 内容が一目で分かる簡潔な名前にする
• issue 番号がある場合は含めても良い（例: feature/123-user-login）

---

基本ルール

🚫 禁止事項

1. master ブランチへの直接 Push

   • master ブランチは本番環境と同期しているため、直接の変更は禁止
   • 必ず develop ブランチ経由でマージする

2. レビューなしでの develop へのマージ

   • Pull Request を作成し、最低 1 名のレビューを得てからマージ

3. 古いブランチでの長期作業

   • 定期的に develop ブランチの最新状態を取り込む

✅ 推奨事項

1. 小さな単位でのコミット

   • 1 つのコミットには 1 つの変更内容
   • コミットメッセージは分かりやすく具体的に

2. こまめな Push

   • ローカルでの作業が溜まりすぎる前にリモートへ Push

3. コンフリクトの早期解決

   • develop ブランチの更新を定期的に取り込み、コンフリクトを最小化

---

作業手順

1. 新規作業の開始

develop ブランチから最新のコードを取得し、作業ブランチを作成します。

# developブランチに移動
git checkout develop

# 最新の状態に更新
git pull origin develop

# 作業ブランチを作成して移動
git checkout -b feature/your-feature-name

2. 開発作業

コードの変更を行い、適宜コミットします。

# 変更内容を確認
git status

# 変更をステージング
git add .
# または特定のファイルのみ
git add path/to/file

# コミット（分かりやすいメッセージを記述）
git commit -m "Add: ユーザーログイン機能の実装"

# リモートにPush
git push origin feature/your-feature-name

コミットメッセージの書き方:

• Add: 新規機能追加
• Fix: バグ修正
• Update: 既存機能の更新
• Remove: 不要なコード削除
• Refactor: リファクタリング

3. develop ブランチの最新状態を取り込む

作業中に develop ブランチが更新された場合、定期的に取り込みます。

# developブランチの最新状態を取得
git fetch origin develop

# 作業ブランチにdevelopの変更をマージ
git merge origin/develop

# コンフリクトがある場合は解決してコミット
# コンフリクト解決後
git add .
git commit -m "Merge: developブランチの最新状態を取り込み"
git push origin feature/your-feature-name

4. Pull Request の作成

作業が完了したら、Pull Request を作成します。

# 最終確認: テストの実行、コードの整形など

# リモートに最新の状態をPush
git push origin feature/your-feature-name

GitHub 上での操作:

1. リポジトリページで「Pull requests」タブを開く
2. 「New pull request」をクリック
3. base: develop ← compare: feature/your-feature-name を選択
4. タイトルと説明を記入
   • 変更内容の概要
   • 実装した機能の説明
   • テスト方法
   • スクリーンショット（UI 変更の場合）
5. レビュアーを指定
6. 「Create pull request」をクリック

5. コードレビュー

レビュアー:

• コードの内容を確認し、問題があればコメント
• 問題がなければ Approve する

作業者:

• 指摘事項があれば修正して Push（Pull Request は自動更新される）

# 修正を行う
git add .
git commit -m "Fix: レビュー指摘事項の修正"
git push origin feature/your-feature-name

6. develop ブランチへマージ

レビュー承認後、Pull Request をマージします。

GitHub 上での操作:

1. Pull Request ページで「Merge pull request」をクリック
2. マージ方法を選択（推奨: “Squash and merge” または “Create a merge commit”）
3. 「Confirm merge」をクリック

マージ後のローカル作業:

# developブランチに移動
git checkout develop

# 最新の状態に更新
git pull origin develop

# マージ済みの作業ブランチを削除
git branch -d feature/your-feature-name

# リモートブランチも削除
git push origin --delete feature/your-feature-name

7. 本番リリース（master ブランチへの反映）

develop ブランチが安定し、リリース準備が整ったら、master ブランチへマージします。

# masterブランチに移動
git checkout master

# 最新の状態に更新
git pull origin master

# developブランチをマージ
git merge develop

# タグを作成（バージョン管理）
git tag -a v1.0.0 -m "Release version 1.0.0"

# masterブランチとタグをPush
git push origin master
git push origin v1.0.0

# developブランチに戻る
git checkout develop

注意事項:

• master へのマージは慎重に行う
• リリース前に十分なテストを実施
• バージョンタグを必ず付ける

---

トラブルシューティング

コンフリクトが発生した場合

# コンフリクトが発生したファイルを確認
git status

# エディタでコンフリクトを解決
# <<<<<<< HEAD と >>>>>>> の間を編集

# 解決後、ステージング
git add .

# マージを完了
git commit -m "Resolve: コンフリクトを解決"

# リモートにPush
git push origin feature/your-feature-name

誤って master に Push してしまった場合

# 直前のコミットを取り消す（まだPushしていない場合）
git reset --soft HEAD^

# 既にPushしてしまった場合はチームに相談し、revertコミットを作成
git revert HEAD
git push origin master

ブランチを間違えて作成した場合

# 正しいブランチに移動
git checkout develop

# 新しいブランチを作成
git checkout -b feature/correct-name

# 間違ったブランチを削除
git branch -d feature/wrong-name

---

チーム内コミュニケーション

ベストプラクティス

コミット

• 1 コミット 1 変更: 複数の変更は分けてコミット
• 意味のあるメッセージ: 何を変更したかが分かるように記述
• テスト済みコードのみ: 動作確認してからコミット

ブランチ

• 短命なブランチ: 1〜3 日で完了する単位で作業
• 定期的なマージ: develop の変更をこまめに取り込む
• 削除: マージ後は速やかにブランチを削除

レビュー

• 迅速なレビュー: 可能な限り早くレビューを行う
• 具体的なフィードバック: 「良くない」ではなく「〇〇の理由で △△ にすべき」
• ポジティブな姿勢: 良い実装には積極的に賞賛

---

付録: よく使う Git コマンド一覧

# ブランチ一覧を表示
git branch -a

# 現在のブランチを確認
git branch

# ブランチを切り替え
git checkout branch-name

# 変更を一時的に退避
git stash

# 退避した変更を復元
git stash pop

# コミット履歴を確認
git log --oneline --graph

# 特定のファイルの変更履歴を確認
git log -- path/to/file

# 直前のコミットメッセージを修正
git commit --amend

# リモートブランチの最新状態を確認
git fetch --all

# ローカルブランチを削除
git branch -d branch-name

# 強制的にブランチを削除
git branch -D branch-name

---

最終更新日: 2025 年 10 月 29 日