========================================================================
Git運用ルール (Git Operation Rules)
========================================================================

1. 基本方針 (Basic Policy)
------------------------------------------------------------------------
チーム開発におけるコードの整合性を保ち，手戻りを防ぐために以下の運用フローを徹底する．

・メインブランチ (main):
    - 本番環境または常に動作可能な状態を維持するブランチ．
    - 直接のコミット（直プッシュ）は禁止する．必ずプルリクエスト（PR）経由でマージする．
・作業ブランチ (Feature Branch):
    - 機能追加やバグ修正ごとに `main` から派生させて作成する．
    - 作業完了後，`main` へマージし，原則として削除する．
・`.gitignore`:
    - リポジトリ作成時に必ず整備する．
    - ビルド成果物，依存パッケージ（`node_modules/` 等），環境変数ファイル（`.env` 等）は必ず除外する．
    - `git add .` を安全に使うための前提条件であるため，メンバー追加時にも確認する．


2. ブランチ命名規則 (Branch Naming)
------------------------------------------------------------------------
2-1. プレフィックス (Prefix)
作業の種類を一目で判別するために，以下のプレフィックスを使用する．

■ カテゴリ一覧
    ・feature/: 新機能の実装，仕様変更
    ・fix/: バグ修正
    ・refactor/: コードの整理（挙動は変えない）
    ・docs/: ドキュメントの追記・修正
    ・chore/: ビルド設定やツール導入など，雑多な作業

2-2. 書式 (Format)
    ・書式: `[プレフィックス][概要]`
    ・区切り: スラッシュ `/` を使用する．概要内の単語区切りはハイフン `-` を使用する．
    ・概要: 作業内容を端的に表す英単語2〜4語程度（小文字）とする．
    ・例:
        - feature/player-jump
        - fix/collision-bug
        - docs/guide-update


3. 開発フロー (Development Workflow)
------------------------------------------------------------------------
作業を開始してからマージされるまでの手順．

1. ローカルの最新化
    ・作業開始前は必ず `main` ブランチに切り替え，リモートの最新状態を取り込む．
    ・コマンド:
        $ git checkout main
        $ git pull origin main

2. 作業ブランチの作成
    ・最新の `main` から新しいブランチを作成して移動する．
    ・コマンド:
        $ git checkout -b feature/new-function

3. 実装とコミット
    ・作業単位（意味のあるまとまり）ごとにコミットする．
    ・巨大なコミットは避け，レビューしやすい粒度を心がける．
    ・VS CodeでCopilotを使用している場合，AIによるコミットメッセージの生成機能（キラキラアイコン等）を利用してもよい．
      ただし，生成されたメッセージは必ず「4. コミットメッセージ」の書式ルール（タグや日本語化）に合わせて修正すること．
    ・コマンド:
        $ git add .
        $ git commit -m "[add] 新機能を実装"

4. リモートへのプッシュ
    ・作業ブランチをリモートリポジトリへ送信する．
    ・コマンド:
        $ git push origin feature/new-function

5. プルリクエスト (PR) の作成
    ・GitHubのリポジトリ画面上部に表示される「Compare & pull request」ボタンをクリックする．
    ・Baseを `main`、Compareを自分の「作業ブランチ」に設定する．
    ・「Reviewers」メニューからチームメンバーを選択し、レビューを依頼する．
    ・「Create pull request」ボタンを押してPRをオープンする．

6. レビューと修正の対応
    ・レビュワーのコメントを確認し、修正が必要な場合はローカルで修正・コミット・プッシュを繰り返す．
    ・GitHub上で全ての指摘に対し「Resolve conversation」を行い、やり取りを完了させる．
    ・レビュワーから「Approve（承認）」のスタンプまたはメッセージをもらう．

7. マージの実行（マージボタンの操作）
    ・PR画面下部の「Merge pull request」ボタンをクリックする．
    ・マージ方式は「Create a merge commit」を選択する（作業ブランチの全コミット履歴が `main` に残る）．
        - 「Squash and merge」「Rebase and merge」は使用しない．
    ・確認用の「Confirm merge」ボタンを押し，`main` への統合を完了させる．
    ・マージ直後に表示される「Delete branch」ボタンを押し，リモート上の作業ブランチを削除する．

8. ローカル環境のクリーンアップ
    ・マージ完了後はローカル環境も最新状態に戻し、古いブランチを削除する．
        $ git checkout main
        $ git pull origin main
        $ git branch -d [作業ブランチ名]


4. コミットメッセージ (Commit Messages)
------------------------------------------------------------------------
4-1. 書式
    ・書式: `[タグ] 内容`
    ・言語: 日本語 (Japanese)
    ・句読点: 末尾に句点は不要．

4-2. タグ一覧
    ・[add]: ファイルや機能の追加
    ・[update]: 機能やデータの更新・修正
    ・[fix]: バグ修正
    ・[remove]: 削除
    ・[clean]: 整理，リファクタリング


5. トラブルシューティング (Troubleshooting)
------------------------------------------------------------------------
■ コンフリクト (Conflict) が発生した場合
他メンバーの変更と競合した場合の対処手順．

1. main の取り込み
    ・作業ブランチに `main` の最新内容をリベースして競合箇所を洗い出す．
    ・`merge` ではなく `rebase` を使うことで，履歴が線形に保たれレビューしやすくなる．
    ・コマンド:
        $ git checkout main
        $ git pull origin main
        $ git checkout feature/new-function
        $ git rebase main

2. 競合の解消
    ・エディタ上で `<<<<<<<`, `=======`, `>>>>>>>` で囲まれた箇所を手動で修正する．
    ・修正後，以下のコマンドでリベースを続行する．
        $ git add [修正したファイル]
        $ git rebase --continue
    ・全ての競合が解消されたらプッシュする．リベース後は履歴が書き換わるため `-f` オプションが必要になる．
        $ git push -f origin feature/new-function

■ 間違えて main にコミットしてしまった場合

1. まだプッシュしていない場合
    ・コミットを取り消し，変更内容を保持したまま新しいブランチへ移動する．
    ・コマンド:
        $ git reset --soft HEAD^
        $ git checkout -b feature/new-function
        $ git commit -m "[add] ..."

2. すでにプッシュしてしまった場合
    ・`main` への force push はチーム全員の履歴を壊す危険があるため，自分では対処しない．
    ・直ちにチームメンバーに報告し，全員で対応方針を決める．