言語規約

プロジェクトから言語スタイルを推測:

• 既存のブランチ、コミットメッセージ、ドキュメントを分析して、プロジェクトの言語バリアント(米国英語、英国英語など)を検出する
• プロジェクトで見つかったスペル規則に合わせる(例: "synchronize" vs "synchronise"、"center" vs "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/など)、そのままにしておいてください。

4. ブランチ名を検証

包括的な検証を適用してください:

ケバブケース(Kebab-Case)の強制

• 小文字に変換
• スペースとアンダースコアをハイフンに置き換え
• フォーマットが prefix/kebab-case-name であることを確認

文字の検証

以下を含むブランチ名を拒否してください:

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

長さの検証

• 最小: 3文字(プリフィックス除外)
• 最大: 100文字(合計)

5. 重複をチェック

ローカルブランチとリモートブランチの両方をチェックしてください:

# ローカルブランチをチェック
git branch --list "<branch-name>"

# リモートブランチをチェック
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統合

ユーザー: "Issue #456 のブランチを作成して"
コマンド: gh issue view 456
出力: #456 - Add user authentication (open)
コマンド: gh issue develop 456 -c
出力: Created and checked out branch: feature/456-add-user-authentication

例2: 自動プリフィックス付き手動

ユーザー: "Create branch: fix login bug"
分析: "fix" を含む → "bugfix/" プリフィックスを適用
検証済み: "bugfix/login-bug"
コマンド: git checkout -b bugfix/login-bug main

例3: カスタムプリフィックス

ユーザー: "Create branch: docs/update readme"
分析: 既に "docs/" プリフィックスがある → そのままにする
検証済み: "docs/update-readme"
コマンド: git checkout -b docs/update-readme main

ベストプラクティス

1. Issue番号が言及されている場合、常にGitHub Issueワークフローを優先する
2. git エラーを避けるため、作成前に徹底的に検証する
3. 目的を明確に示す説明的な名前を使用する
4. チームの規則に従う - 既存のブランチ名をパターン確認のためチェック
5. リモートに早期にプッシュする - バックアップとコラボレーションのため
6. 可能な限りブランチをIssueにリンク - プロジェクト追跡の向上のため