git-workflow

Git ワークフロー

このスキルは、リポジトリのルーティング優先のローカル Git コラボレーションと復旧の拠り所として使用します。

目的は、Git のすべてを教えることではありません。目的は次のとおりです。

• 現在のローカル Git の状態をすばやく把握する
• 安全なワークフローモードを 1 つ選ぶ
• 問題を解決する、最小限で元に戻せる修正を推奨する
• レビュー、デバッグ、計画、ホスト型 PR ワークフローとの境界を明確に保つ

判断が難しいケースや、概要以上の情報が必要な場合は、次のリファレンスを参照してください。

• references/collaboration-boundaries.md
• references/mode-selection-and-command-packets.md
• references/recovery-patterns.md

主なニーズが次の場合：

• 差分の正確性、アーキテクチャ、セキュリティのレビュー → code-review に振り分ける
• バグやリグレッションの再現または診断 → debugging に振り分ける
• タスク、受け入れ基準、スプリントの作業単位の計画 → task-planning に振り分ける
• Aider ベースの AI ペアプログラミング編集ループの運用 → aider-cli-workflow に振り分ける
• ホスト型 PR のライフサイクル、ブランチ保護、レビュアー、ラベル、リポジトリ設定 → 専用の PR／リポジトリ管理ワークフローを使用する

このスキルを使用する場面

• コーディングやレビューの前にブランチを作成、名前変更、または整理する
• 変更を選択的にステージングし、レビューしやすいコミットにまとめる
• 更新されたベースブランチにマージするかリベースするかを判断する
• マージ／リベースのコンフリクトを安全に解決する
• ブランチをプッシュする、アップストリームを設定する、または --force-with-lease で書き換えた履歴を更新する
• 不適切なリセット、誤ったブランチへのコミット、detached HEAD、コミットの消失、または混乱したリベースから復旧する
• 後続の PR やレビューに備えて、きれいな差分を準備する

このスキルを使用しない場面

• 本当の問いが、コードやアーキテクチャの良し悪しである
• 本当の問いが、作業の分割方法や順序である
• 本当の問いが Git の操作ではなく、根本原因である
• 本当の問いがローカルリポジトリの状態ではなく、ホスト型サービスのワークフローである
• ユーザーが次の安全な手順ではなく、膨大な Git チュートリアルを求めている

手順

ステップ 1：ローカル Git の情報を整理する

コマンドを提案する前に、依頼を分類します。

git_intake:
  current_goal: branch-setup | commit-shaping | sync-with-base | conflict-resolution | push-safety | undo-recovery | history-inspection | unknown
  branch_state: clean | has-unstaged-changes | staged-only | ahead-of-origin | behind-origin | diverged | detached-head | unknown
  collaboration_risk: solo-branch | shared-branch | unknown
  remote_context: no-remote | origin-only | fork-plus-upstream | unknown
  trigger_event:
    - need-clean-commits
    - rebased-branch
    - merge-conflict
    - wrong-branch-commit
    - accidental-reset
    - rejected-push
    - lost-commit
    - prepare-for-review
    - sync-main
    - unclear
  preferred_history: keep-linear | preserve-merge-context | unknown
  confidence: high | medium | low

情報が不足している場合は、妥当な範囲で最も安全な次の手順を選び、前提を明示します。

ステップ 2：主要なワークフローモードを 1 つ選ぶ

次のモードから、必ず 1 つだけ選びます。

1. branch-and-stage hygiene — ブランチの作成／切り替え、ステージング、stash または clean の判断
2. commit-shaping — amend、fixup、reword、インタラクティブリベース、レビューしやすい単位への整理
3. sync-with-base — ブランチを最新の状態にするための fetch と、マージ／リベースの選択
4. conflict-resolution — マージ／リベースですでにコンフリクトが発生しており、次の安全な手順が最も重要な場合
5. push-safety — アップストリームの設定、拒否されたプッシュ、分岐したブランチ、履歴を書き換えて安全にプッシュする場合
6. undo-and-recovery — reset／rebase／amend／checkout／ブランチ削除で問題が起きた場合。まず救出する

ステップ 3：安全性の段階を踏む

取り消せない操作の前には、必ず次の確認を優先します。

• git status
• git branch --show-current
• git log --oneline --decorate -5

基本ルール：

• コミットの境界が重要な場合は、git add -p または明示的なステージングを優先します。
• amend またはインタラクティブリベースは、ローカルの履歴、または安全に書き換えられる履歴に対してのみ使用します。
• ブランチが主に自分のものであり、レビューしやすい履歴が有用な場合は、リベースを優先します。
• ブランチが共有されている場合、統合の経緯が重要な場合、または履歴を直線化する価値より書き換えのリスクが大きい場合は、マージを優先します。
• 意図的に履歴を書き換えた後は、git push --force-with-lease を優先し、通常の --force は決して使用しません。
• 問題のあるコミットがすでに共有されている場合は、reset --hard より git revert を優先します。
• 慌ててクリーンアップする前に、git reflog と救出用ブランチを優先します。

ステップ 4：判断の指針を適用する

次の説明を明示的に使用します。

マージとリベースの比較

• 書き換えのリスクが低く、レビューしやすい直線的な履歴が重要な場合は、リベースを使用します。
• ブランチが共有されている場合、統合の経緯が重要な場合、または書き換えのリスクに見合う価値がない場合は、マージを使用します。

revert と reset の使い分け

• すでにプッシュされた履歴を共同作業で取り消す場合は、revert を使用します。
• ローカル履歴を意図的に書き換える場合に限り、reset を使用します。
• ブランチ履歴よりも作業ツリー／インデックスの修復が必要な場合は、ファイルの restore／checkout を使用します。

通常の push と --force-with-lease

• 履歴を書き換えていない場合は、通常の push を使用します。
• rebase、amend、squash、またはその他の意図的な書き換えの後は、--force-with-lease を使用します。
• ブランチが共有されている可能性があり、リモートの状態が不明な場合は、作業を止めて共同作業上のリスクを明示します。

ステップ 5：Git ワークフローの概要を作成する

次の構成をそのまま返します。

# Git Workflow Brief

## Recommended mode
- Mode: branch-and-stage hygiene | commit-shaping | sync-with-base | conflict-resolution | push-safety | undo-and-recovery
- Why this mode fits: ...

## Current state
- Branch: ...
- Worktree / index state: ...
- Remote context: ...
- Collaboration risk: solo-branch | shared-branch | unknown
- Confidence: high | medium | low

## Safest next move
1. ...
2. ...
3. ...

## Commands
```bash
...

この方法が安全な理由

• ...
• ...

注意点

• ...
• ...

復旧時の代替手段

• 問題が発生した場合は、... を使用します。

関連する引き継ぎ

• ... の場合は code-review を使用します。
• ... の場合は debugging を使用します。
• ... の場合は task-planning を使用します。

### Step 6: Use concise mode packets
- **branch-and-stage hygiene** — branch name, dirty/clean state, selective staging, stash only when it lowers risk
- **commit-shaping** — reviewable commit units, amend/fixup/rebase only when rewrite is safe
- **sync-with-base** — fetch first, decide merge vs rebase explicitly, name rewrite risk before starting
- **conflict-resolution** — inspect → resolve → `git add` → continue/commit, with `abort` as the calm fallback
- **push-safety** — distinguish upstream creation, normal push, rejected push, and rewritten-history push
- **undo-and-recovery** — identify what moved, inspect `reflog`, create a rescue branch, prefer reversible steps first

Use the detailed command packets in [references/mode-selection-and-command-packets.md](references/mode-selection-and-command-packets.md) when you need the expanded workflow.

### Step 7: Keep boundaries sharp
Before finalizing:
- Do **not** turn this into a hosted PR tutorial.
- Do **not** pretend every branch should be rebased.
- Do **not** recommend `reset --hard` casually without naming the data-loss risk.
- Do **not** hide the solo-vs-shared branch distinction.
- Do **not** drift into code-review judgment, root-cause analysis, or backlog design.

## Output format
Always return a compact **Git Workflow Brief**, not a giant command dump.

Required qualities:
- choose one mode
- state the collaboration risk
- prefer the safest reversible path that solves the current problem
- make rewrite risk explicit
- include a recovery fallback when the commands have teeth
- keep routing boundaries to review, debugging, planning, and hosted PR workflows visible

## Examples

### Example 1: rebased branch needs safe push
**Input**
> I rebased my feature branch onto main and now I need to push it without overwriting teammates.

**Output sketch**
- Mode: `push-safety`
- State whether the branch looks solo or shared
- Recommend `git push --force-with-lease origin <branch>` only if rewrite is expected
- Watch-out warns against raw `--force`

### Example 2: clean up local commits before review
**Input**
> Help me turn these messy local commits into something clean before review.

**Output sketch**
- Mode: `commit-shaping`
- Suggest explicit staging plus `git rebase -i` or `git commit --amend`
- Keep the goal focused on reviewable commit units, not review comments themselves

### Example 3: wrong-branch reset panic
**Input**
> I think I hard-reset the wrong branch. Can Git recover this?

**Output sketch**
- Mode: `undo-and-recovery`
- Start with `git reflog`
- Create a rescue branch from the pre-reset SHA before further cleanup
- Explain when to stop and avoid more destructive commands

### Example 4: request is really PR review
**Input**
> Review this PR and tell me if the architecture is okay.

**Output sketch**
- Route away from `git-workflow`
- Explain that local Git prep is not the main problem here
- Hand off to `code-review`

## Best practices
1. **Inspect before surgery.** Status, branch, and recent log beat guesswork.
2. **Prefer reviewable commits over giant snapshots.** Commit shape affects review quality.
3. **Treat history rewrites as collaboration decisions, not personal preferences.** Shared branches change the answer.
4. **Use `--force-with-lease`, not raw `--force`.** Rewrite safely or do not rewrite.
5. **Reach for `reflog` early in recovery.** Lost commits are often only misplaced pointers.
6. **Choose the smallest safe fix.** Not every problem needs branch surgery.
7. **Route out when the problem changes.** Review, debugging, planning, and hosted PR work stay separate.

## References
- [references/collaboration-boundaries.md](references/collaboration-boundaries.md)
- [references/mode-selection-and-command-packets.md](references/mode-selection-and-command-packets.md)
- [references/recovery-patterns.md](references/recovery-patterns.md)
- Git documentation — https://git-scm.com/docs
- GitHub Docs, *Resolving merge conflicts after a Git rebase* — https://docs.github.com/en/get-started/using-git/resolving-merge-conflicts-after-a-git-rebase
- GitLab Docs, *Resolve conflicts from the command line* — https://docs.gitlab.com/topics/git/git_rebase/#resolve-conflicts-from-the-command-line