Git ブランチ管理
すべての変更は独自のブランチで行います。これは1行の修正や、Issueがない変更も含みます。ベースブランチにコミットしてはいけません。
1. ベースブランチを見つける
最初に回答が得られる情報源を使用します:
- リポジトリの指示.
CLAUDE.md、CONTRIBUTING.md、.github/内の文書を読みます。ベースブランチまたは統合ブランチが指定されていれば、それを使用します。 - リモートのデフォルトブランチ.
git symbolic-ref --short refs/remotes/origin/HEAD # origin/<name> を表示 gh repo view --json defaultBranchRef -q .defaultBranchRef.name - 曖昧な場合. リモートに
developやdevelopmentがあり、どのブランチがベースか文書に記載がない場合は、ユーザーに尋ねます。推測してはいけません。
統合ブランチ（例: develop）がベースの場合、リリース版に対するホットフィックスはデフォルトブランチから開始します。これはユーザーがその作業をホットフィックスと呼んだ場合のみ使用します。
2. 現在位置を確認する
git status --porcelain
git rev-parse --abbrev-ref HEAD
- ワーキングツリーに自分が行っていない変更がある場合は、停止し、ユーザーにどうするか尋ねます。
- すでにこの作業のブランチにいる場合は、そのままそこに留まります。
- ベースブランチ上に自分が行った未コミットの編集がある場合は、それらを移動します:
git switch -c <name>でワーキングツリーに保持されます。
3. リモートの先端からブランチを開始する
git fetch origin --prune
git switch -c <name> origin/<base>
git log -1 --oneline
origin/<base> から開始することで、古いローカルベースブランチがあっても問題になりません。ベースブランチで git pull を実行して「追いつく」必要はありません。必須ではありません。
4. ブランチに名前を付ける
リポジトリの規則があればそれに従います。ない場合は、<type>/<ref>-<slug> を使用します:
| 部分 | 値 |
|---|---|
type | feat、fix、docs、chore、refactor、test、release、hotfix |
ref | Issue番号 (42)、パイプラインチケット (ticket-007)、またはなし |
slug | 2〜5語の小文字単語をハイフンで結合 |
例: fix/42-null-session-crash、feat/ticket-007-search-filters、docs/readme-install-steps。
5. 作業中の注意点
- それぞれが単独で意味をなす小さな単位でコミットします。件名は命令形で72文字以内に書きます。本文では理由を説明します。
- コミットメッセージに
Co-Authored-By: Claudeトレーラーを追加してはいけません。これは gener8v のルールです。 - 最初のプッシュ前は、
origin/<base>にリベースできます。ブランチがプッシュされた後は、代わりにベースをブランチにマージします。プッシュされたブランチのリベースは履歴を書き換えるため、engineering:git-safetyがそれを制御します。 - 最初の失敗で停止するチェーンでプッシュします:
set -o pipefail git fetch origin && <テストコマンド> 2>&1 | tail -n 40 && git push -u origin HEADset -o pipefailがないと、| tailがその前のコマンドの終了コードを隠してしまいます。Gitコマンドやテストコマンドをtailにパイプする際は、必ずこの設定を行ってください。
並行作業
同時にコードを編集する2つ以上のエージェントについては、エージェントを開始する前に resources/parallel-work.md を読んでください。簡単に言うと: ベースから1つのバッチブランチ、バッチブランチからエージェントごとに1つのワークツリーと1つのブランチ、そして同じファイルを扱うエージェントはありません。
完了条件
- 明確な名前のブランチ上にあり、そのブランチが現在の
origin/<base>から始まっていること。 git statusが他人の変更を表示しないこと。
関連スキル
engineering:github-pr-merge: 作業完了時にPRを作成します。engineering:git-safety: フォースプッシュ、ブランチ削除など類似コマンドの承認ルール。engineering:github-issue-workflow: Issueまたはパイプラインチケットの全ライフサイクル。このスキルを最初に呼び出します。