mcpField
B
branch-policy

branch-policy

github.com/loxosceles-dev開発79 回インストール
リポジトリ

branch-policy について

branch-policyは、devを統合ブランチとし、プルリクエストで変更を進めるGitブランチ手順を定めるスキルです。機能開発や修正、レビューで共通ルールを使うチーム向けです。

主な機能

  1. 01コーディング前にdevからブランチ作成
  2. 02機能・修正・保守用のブランチを分離
  3. 03機能ブランチのPR先をdevに設定
  4. 04レビュー修正を同じブランチに保持
  5. 05PRでdevをmainにマージ

活用シーン

  1. 01作業開始前に作業ブランチを作成
  2. 02機能や修正をdevに向けてレビュー依頼
  3. 03既存ブランチでPRレビューの指摘に対応

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/loxosceles-dev/dev-skills --skill branch-policy

インストール後、Claude Code で/branch-policyを入力して読み込まれたか確認します。

詳細

ブランチポリシー

ブランチモデル

main        ← production. Updated ONLY by PR from dev. Never push directly.
dev         ← integration branch. Updated ONLY by PR from feature branches.
feat/*      ← feature work, branched FROM dev
fix/*       ← bug fixes, branched FROM dev
chore/*     ← maintenance, branched FROM dev

最優先ルール：必ず最初にブランチを作成する

コードを1行でも書く前に、dev から機能／修正／雑務用ブランチを作成してください。

次のことはしないでください：

  • dev でコーディングを始めて、「後でブランチに移す」
  • 「簡単な修正」をdevに直接プッシュする
  • 小さな変更ならブランチは不要だと思い込む

devにいて変更を加えようとしている場合は、作業を止めて次を実行してください：

git checkout -b feat/descriptive-name dev

1つの機能につき1つのブランチ

機能ブランチは、その機能が完了するまで使います。関連するすべての作業はそのブランチで行います：

  • PR のレビューコメントへの対応 → 同じブランチで修正してプッシュ
  • Copilot のコメントへの対応 → 同じブランチで修正してプッシュ
  • 複数回の反復作業 → 同じブランチ

オープン中の PR のレビューで見つかった問題に対して、新しいfix/ブランチを作成しないでください。PR がマージされるまで機能ブランチを使い続けてください。

新しいブランチが必要なのは、本当に新規で、関連のない作業を始める場合だけです。

フロー

  1. git checkout -b feat/thing dev — コードを変更する前にブランチを作成
  2. 機能ブランチでコミットを作成
  3. 機能ブランチをプッシュし、dev宛てに PR を作成（main宛てにはしない）
  4. 同じブランチでレビューコメントに対応し、再度プッシュ
  5. 承認後、PR をdevにマージ
  6. devが安定したら、devからmain宛てに PR を作成

プッシュのルール

操作許可されるか
機能ブランチへのプッシュ✅ 常に許可
devへのプッシュ❌ ユーザーが「push to dev」と明示した場合のみ
mainへのプッシュ❌ 禁止。mainは PR のマージによってのみ更新します。

devにいるときにユーザーから「これをコミットして」または「コミットしよう」と言われた場合は、プッシュしないでください。「このための機能ブランチを作成しますか？」と確認してください。

PR のベースブランチ

ソースブランチPR のベース
feat/*、fix/*、chore/*dev
devmain

機能ブランチから--base mainを指定して PR を作成しようとしている場合は、作業を止めてください。ベースはdevでなければなりません。

Devcontainer — SSH と AWS

SSH キーは~/.ssh/contexts/personal/から/home/vscode/.sshに直接マウントされています。 エージェント転送はありません。SSH_AUTH_SOCKは関係ありません。git pushが機能するのは、キー ファイルがそこにあるためであり、転送されたソケットがあるためではありません。

初回のプッシュ前に確認してください：

ssh -T [email protected]    # must say "Hi loxosceles!"
aws sts get-caller-identity    # must return account info

SSH に失敗する場合は、ホスト上に~/.ssh/contexts/personal/id_ed25519が存在すること、およびknown_hostsにgithub.comのエントリーがあることを確認してください。AWS に失敗する場合は、~/.aws/contexts/<name>/credentialsに有効な[default]プロファイルがあることを確認してください。どのコンテキストがマウントされるかは.devcontainer/docker-compose.ymlに記載されています。

よくある避けるべき間違い

  1. ブランチを作成せずに作業を始める — コーディング前に必ずgit branch --show-currentを確認してください。結果がdevなら、まずブランチを作成してください。
  2. 「小さな修正」をdevにプッシュする — ブランチと PR のフローを省略できるほど小さな修正はありません。後で cherry-pick が大変になります。
  3. 機能ブランチからmain宛てに PR を作成する — 機能ブランチの宛先は常にdevです。
  4. ユーザーから「X をやろう」と言われた後、ブランチの作成を忘れる — 新しいタスクでは、最初にgit checkout -bを実行してください。
  5. レビュー対応のために新しいブランチを作成する — 現在の機能ブランチを使い続けてください。マージされるまで、1つの機能につき1つのブランチです。

コメント

Markdown 対応