branch-naminglisted

# ブランチ命名規則の探索と決定 プロジェクト内からブランチ命名規則を探し、見つかればそれに従った名前を、 無ければテンプレート既定の形式を返す。 ## 探索の手順(見つかった時点で確定し、以降は探さない) 0. **キャッシュ確認**: docs/branch-convention.md が存在すればそれを読み、 記載された規約をそのまま使う(探索をスキップ)。 1. **CONTRIBUTING.md / CONTRIBUTING.ja.md**(リポジトリルートと docs/ 配下): 「ブランチ」「branch」「命名」「naming」を含むセクションを探す。 2. **README.md**: 同様のセクションを探す。 3. **docs/ 配下の開発ガイド**: development.md, workflow.md, git*.md 等。 4. **.github/ 配下**: PULL_REQUEST_TEMPLATE.md、workflows/*.yml 内の ブランチ名検証(正規表現)を探す。正規表現があればそれが規約。 **例外**: 手順1〜3の文書で規約を**新規に**見つけた場合も、この手順4 (CI の検証正規表現)だけは必ず確認し、文書と CI が矛盾したら CI を 採用する(文書が古くても CI は実際にブロックするため)。手順0の キャッシュ命中時はこの確認も不要(キャッシュは前回この確認を経て 確定した結果のため)。また、どの手順でも「廃止」「deprecated」等の 明記がある記述は採用せず次の候補へ進む。 5. **既存ブランチの実績分析**: `git branch -a --format='%(refname:short)'` を実行し、 スラッシュ区切りの最初のセグメント(プレフィックス)の頻度を集計する。 同一プレフィックスが3本以上あれば、それを事実上の規約とみなす (例: feature/ が5本 → feature/<説明> 形式を採用)。 main / master / develop / HEAD / origin 系は集計から除外する。 6. **どこにも無い場合**: テンプレート既定の `pipeline/YYYYMMDD-<トピック>` を使う。 ## 名前の生成ルール - 規約が見つかった場合、その形式に従う。種類(feature/fix/refactor 等)は 依頼内容から判断する(新機能→feature、バグ修正→fix、等) - 説明部分は依頼内容から2〜4語の英語 kebab-case で生成する (規約が snake_case を指定していればそれに従う) - Issue 番号や日付が規約に含まれる場合、日付は今日、Issue 番号は ユーザーに確認する(勝手に番号を作らない。no-guess) ## キャッシュの保存 規約を確定したら(既定へのフォールバック時を除く)、docs/branch-convention.md に 以下の形式で保存する。次回からは手順0で即決できる。 このテンプレートのリポジトリでは docs/ は .gitignore 対象(git 管理外)のため この保存はコミットされない(下流プロジェクトでは各自の .gitignore 設定に依るため、 挙動が異なる場合がある)。 # ブランチ命名規則(自動検出)