create-branch

言語規約

プロジェクトの言語スタイルを推定します：

• 既存のブランチ、コミットメッセージ、ドキュメントを分析し、プロジェクトの言語のバリエーション（米国英語、英国英語など）を特定します
• プロジェクトで使われている綴りの規則に合わせます（例：「synchronize」と「synchronise」、「center」と「centre」）
• ブランチ名やコマンド出力全体で、プロジェクトに確立された言語スタイルとの一貫性を保ちます

---

ブランチ作成コマンド

このコマンドは、適切な検証と GitHub Issue との連携を行い、新しい git ブランチを作成してチェックアウトします。

優先事項：GitHub Issue との連携

重要：ユーザーが Issue 番号（例：「#123」、「123」、「issue 123」）を指定した場合は、必ず GitHub CLI の Issue 開発ワークフローの利用を優先してください：

1. GitHub CLI が利用可能か確認します：

   gh --version
   

   利用できない場合はユーザーに伝え、手動でのブランチ作成に切り替えます。

2. Issue が存在することを確認します：

   gh issue view <issue-number>
   

   確認のため、Issue のタイトルとステータスを表示します。

3. Issue に紐づくブランチを作成します：

   gh issue develop <issue-number> -c
   

   • -c フラグにより、新しく作成したブランチが自動的にチェックアウトされます
   • GitHub は Issue のタイトルから適切なブランチ名を自動生成します
   • プロジェクトの追跡を効率化するため、ブランチが Issue に紐づけられます

4. リモートへのプッシュ手順（以下の手順 8）に進みます

手動でのブランチ作成ワークフロー

Issue 番号が指定されていない場合は、次のワークフローに従います：

1. リポジトリのステータスを確認する

git status

次の点を確認します：

• 作業ディレクトリがクリーンである、または未コミットの変更が許容されること
• 現在のブランチ情報
• git リポジトリ内にいるかどうか

2. ブランチ名を入力してもらう

希望するブランチ名をユーザーに尋ねます。どのような形式で入力しても構いません。コマンドが形式の調整と検証を行います。

3. プレフィックスを自動検出して適用する

ブランチ名の入力に含まれるキーワードを分析し、適切なプレフィックスを自動的に追加します：

• feature/ - キーワード：「add」、「implement」、「create」、「new」、「feature」
• bugfix/ - キーワード：「fix」、「bug」、「resolve」、「patch」、「repair」
• hotfix/ - キーワード：「hotfix」、「urgent」、「critical」、「emergency」
• chore/ - キーワード：「chore」、「refactor」、「update」、「upgrade」、「maintain」
• docs/ - キーワード：「docs」、「documentation」、「readme」、「guide」

ユーザーの入力がすでに認識済みのプレフィックス（feature/、bugfix/ など）で始まっている場合は、そのまま使用します。

4. ブランチ名を検証する

包括的な検証を行います：

ケバブケースの適用

• 小文字に変換します
• スペースとアンダースコアをハイフンに置き換えます
• 形式が prefix/kebab-case-name であることを確認します

文字の検証

次の文字を含むブランチ名は拒否します：

• スペース（ハイフンに変換）
• 特殊文字：~、^、:、?、*、[、]、\、@{、..
• 制御文字または非 ASCII 文字（ハイフンとスラッシュを除く）
• 先頭または末尾のスラッシュやハイフン

長さの検証

• 最小：3 文字（プレフィックスを除く）
• 最大：100 文字（全体）

5. 重複を確認する

ローカルとリモートの両方のブランチを確認します：

# Check local branches
git branch --list "<branch-name>"

# Check remote branches
git ls-remote --heads origin "<branch-name>"

ブランチがすでに存在する場合：

• ローカル：既存のブランチをチェックアウトするか、ユーザーに確認します
• リモート：ユーザーに警告し、別の名前を提案します
• 両方：ユーザーに伝え、チェックアウトするか別の名前を選ぶかを尋ねます

6. ベースブランチを決定する

適切なデフォルトを使用します：

1. main が存在するか確認します：

   git rev-parse --verify main
   

2. 存在しない場合は、master が存在するか確認します：

   git rev-parse --verify master
   

3. どちらも存在しない場合は、現在の HEAD を使用します

4. 必要であれば、ユーザーが別のベースブランチを指定できるようにします（作成前に尋ねます）

7. ブランチを作成してチェックアウトする

git checkout -b <validated-branch-name> <base-branch>

次の情報を示すメッセージで、作成が成功したことを確認します：

• ブランチ名
• 使用したベースブランチ
• 現在のステータス

8. リモートへのプッシュを提案する

ユーザーに「このブランチをリモートにプッシュして、トラッキングを設定しますか？」と尋ねます。

はいの場合：

git push -u origin <branch-name>

これにより、次のことが可能になります：

• ブランチのリモートバックアップ
• チームメンバーとの共同作業
• GitHub PR 作成ワークフロー
• GitHub UI でのブランチの表示

エラー処理

明確で実行可能なエラーメッセージを提示します。

• Git リポジトリではありません：「このディレクトリは Git リポジトリではありません。git init で初期化するか、リポジトリに移動してください。」
• GitHub CLI を利用できません：「GitHub CLI（gh）がインストールされていません。https://cli.github.com からインストールするか、手動でブランチを作成してください。」
• Issue が見つかりません：「Issue #123 が見つかりません。Issue 番号を確認するか、手動でブランチを作成してください。」
• 無効なブランチ名です：「ブランチ名に無効な文字が含まれています。次の名前をおすすめします：feature/valid-branch-name」
• ブランチがすでに存在します：「ブランチ feature/existing はすでに存在します。git checkout feature/existing で切り替えるか、別の名前を選んでください。」
• ネットワークの問題：「リモートブランチを確認できません。ローカルでのみ作成を続行します。」

例

例 1：GitHub Issue との連携

User: "Create a branch for issue #456"
Command: gh issue view 456
Output: #456 - Add user authentication (open)
Command: gh issue develop 456 -c
Output: Created and checked out branch: feature/456-add-user-authentication

例 2：自動プレフィックスを使用した手動作成

User: "Create branch: fix login bug"
Analysis: Contains "fix" → apply "bugfix/" prefix
Validated: "bugfix/login-bug"
Command: git checkout -b bugfix/login-bug main

例 3：カスタムプレフィックス

User: "Create branch: docs/update readme"
Analysis: Already has "docs/" prefix → keep as-is
Validated: "docs/update-readme"
Command: git checkout -b docs/update-readme main

ベストプラクティス

1. Issue 番号が言及されている場合は、常に GitHub Issue のワークフローを優先します
2. Git エラーを避けるため、ブランチを作成する前に十分に検証します
3. 目的が明確にわかる説明的な名前を使用します
4. チームの規約に従います。パターンを把握するため、既存のブランチ名を確認してください
5. バックアップと共同作業のため、早めにリモートへプッシュします
6. プロジェクトの進捗をより適切に追跡できるよう、可能な限りブランチを Issue に関連付けます