tomevault-io Git Branch Switcher
このスキルは、Claude Codeがタスク作業を開始する前に、適切なGitブランチを自動的に判断し、切り替えるのを支援します。
コアワークフロー
新しいタスクを開始する際は、以下の決定フロー順に従ってください：
- 現在のブランチの状態を確認する
- ユーザーが意図する作業内容を理解する
- 既存のブランチに関連するものがないか評価する
- 適切なブランチに切り替えるか、新しいブランチを作成する
ブランチ決定ロジック
ステップ 1: 現在のブランチを確認
まず、現在のブランチを特定し、未コミットの変更がないか確認します：
git branch --show-current
git status --short
ステップ 2: タスクを理解する
ブランチに関する決定を下す前に、ユーザーが何に取り組みたいのかを明確に理解します。
タスクが曖昧な場合は、確認のための質問をしてください：
- どのような機能や修正を実装しようとしているのか？
- 既存の作業と関連しているか？
- 変更のスコープ（範囲）はどの程度か？
ステップ 3: 既存のブランチを評価する
ローカルブランチとその最後のコミットメッセージを一覧表示し、どのような作業が存在するかを把握します：
git branch -v
各ブランチについて、ブランチ名や最近のコミットが現在のタスクに関連しているか、最近アクティブだったか、そして新しい作業をこのブランチで続けることが理にかなっているかを検討します。
ステップ 4: ブランチの決定を行う
評価に基づき、以下のロジックに従います：
ケース A: main または master ブランチにいる場合
常に作業用の新しいブランチを作成します：
git checkout -b <branch-name>
ケース B: 関連する既存ブランチにいる場合
現在のブランチがタスクに適切である場合（ブランチ名と最近の作業内容が新しいタスクと一致する場合）、そのブランチに留まり、このタスクに適しているため既存のブランチで作業を継続することをユーザーに伝えます。
ケース C: 無関係なブランチにいる場合
現在のブランチが別の作業用である場合、まず未コミットの変更がないか確認します。 変更がある場合は、先にコミットするかスタッシュ（退避）する必要があることをユーザーに伝えます。
変更の処理が完了したら、mainに戻って新しいブランチを作成します：
git checkout main
git checkout -b <branch-name>
ブランチの命名規則
"Conventional Commits" をベースにしたプレフィックスに従って、明確で説明的なブランチ名を使用してください：
<prefix>/<description>
description（説明）部分は、小文字のケバブケース（ハイフンつなぎ）で、簡潔かつ説明的に（2〜4単語が理想）、実際の作業内容と明確に関連したものにしてください。
良いブランチ名の例：feature/artwork-collections、fix/search-performance、refactor/error-handling、docs/api-documentation など。
重要な考慮事項
未コミットの変更の処理
未コミットの変更がある状態では、絶対にブランチを切り替えないでください。 変更がある場合は、ユーザーに未コミットの変更について伝え、コミットまたはスタッシュを提案し、処理を進める前にユーザーの確認を待ってください。
複数の候補がある場合
タスクに関連する可能性のある既存ブランチが複数ある場合は、ユーザーに選択肢を提示し、それぞれの関連理由を説明した上で、どのブランチを使用するか、あるいは新しいブランチを作成すべきかを尋ねてください。
作成前の確認
新しいブランチを作成する際は、特にタスクの説明が曖昧な場合、作成前にブランチ名をユーザーに簡単に確認してください。
インタラクションの例
例 1: main から開始する場合
ユーザーが「コレクション機能を追加したい」と言った場合。
プロセス：現在のブランチを確認（mainにいる）、既存ブランチをリストアップ（関連ブランチなし）、feature/collections を作成：
git checkout -b feature/collections
応答：「コレクション機能の作業用に、新しいブランチ feature/collections を作成し、切り替えました。」
例 2: すでに関連ブランチにいる場合
ユーザーが「検索最適化の作業を続けたい」と言った場合。
プロセス：現在のブランチを確認（fix/search-performanceにいる）、タスクとの関連性を認識し、現在のブランチに留まる。
応答：「fix/search-performance ブランチで作業を継続します。これは検索最適化の作業に適しています。」
例 3: 間違ったブランチにいる場合
ユーザーが「認証バグを修正する必要がある」と言った場合。
プロセス：現在のブランチを確認（feature/collectionsにいる）、タスクとの不一致を認識、未コミット変更を確認、その後 main に切り替えて新しいブランチを作成：
git checkout main
git checkout -b fix/authentication
応答：「feature/collections から、認証バグ修正用の新しいブランチ fix/authentication に切り替えました。」
ベストプラクティス
- 作業の消失を防ぐため、ブランチを切り替える前には必ず
git statusを確認してください - 行われている作業を明確に示す説明的なブランチ名を使用してください
- 複数の無関係な変更を混ぜるのではなく、各ブランチを単一の機能や修正に集中させてください
- 履歴を明確に保つため、無関係なブランチを再利用するよりも新しいブランチの作成を優先してください
- ブランチに関する決定とその理由を常にユーザーに明確に伝え、リポジトリで何が起きているかをユーザーが理解できるようにしてください
Converted and distributed by TomeVault — claim your Tome and manage your conversions.