Git Workflow

Use this skill as the repo's routing-first local Git collaboration and recovery anchor.

The job is not to teach all of Git. The job is to:

identify the current local Git state quickly,
choose one safe workflow mode,
recommend the smallest reversible fix that solves the problem,
keep boundaries to review, debugging, planning, and hosted PR workflows explicit.

Read these references when the case gets sharp-edged or the user needs more than the brief:

If the main need is:

reviewing a diff for correctness, architecture, or security → route to code-review
reproducing or diagnosing a bug/regression → route to debugging
planning tasks, acceptance criteria, or sprint slices → route to task-planning
Aider 기반 AI pair-programming 편집 루프 운영 → route to aider-cli-workflow
hosted PR lifecycle, branch protection, reviewers, labels, or repo settings → use a dedicated PR/repo-management workflow

When to use this skill

Create, rename, or clean up a branch before coding or review
Stage changes selectively and shape reviewable commits
Decide whether to merge or rebase onto an updated base branch
Resolve merge/rebase conflicts safely
Push a branch, set upstream, or update rewritten history with --force-with-lease
Recover from a bad reset, wrong-branch commit, detached HEAD, dropped commit, or messy rebase
Prepare a clean diff before a later PR or review step

When not to use this skill

The real question is whether the code or architecture is good
The real question is how to split or sequence the work
The real question is root cause, not Git mechanics
The real question is hosted-service workflow instead of local repository state
The user wants a giant Git tutorial instead of the next safe move

Instructions

Step 1: Normalize the local Git intake

Classify the request before suggesting commands.

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

If the packet is incomplete, choose the safest reasonable next move and state the assumptions.

Step 2: Choose one primary workflow mode

Pick exactly one mode:

branch-and-stage hygiene — branch creation/switching, staging, stash-or-clean decisions
commit-shaping — amend, fixup, reword, interactive rebase, cleaner review units
sync-with-base — fetch + merge/rebase choice when the branch must catch up
conflict-resolution — merge/rebase already produced conflicts; the next safe loop matters most
push-safety — upstream setup, rejected pushes, diverged branches, rewrite-safe pushes
undo-and-recovery — reset/rebase/amend/checkout/branch deletion went sideways; rescue first

Step 3: Use the safety ladder

Always prefer these checks before irreversible actions:

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

Core rules:

Prefer git add -p or explicit staging when commit boundaries matter.
Prefer amend or interactive rebase only on local or safely rewritable history.
Prefer rebase when the branch is mostly yours and a cleaner review history helps.
Prefer merge when the branch is shared or preserving integration context matters more than linear history.
Prefer git push --force-with-lease, never raw --force, after intentional history rewrites.
Prefer git revert over reset --hard when the bad commit is already shared.
Prefer git reflog and a rescue branch before panic cleanup.

Step 4: Apply the decision ladder

Use these callouts explicitly:

Merge vs rebase

Use rebase when rewrite risk is low and reviewable linear history matters.
Use merge when the branch is shared, integration context matters, or rewrite risk is not worth it.

Revert vs reset

Use revert for collaborative undo on already-pushed history.
Use reset only when rewriting local history intentionally.
Use restore / checkout of files when the worktree/index needs repair more than the branch history.

Normal push vs `--force-with-lease`

Use normal push when history was not rewritten.
Use --force-with-lease after rebase, amend, squash, or another intentional rewrite.
If the branch may be shared and the remote state is unclear, stop and name the collaboration risk.

Step 5: Build the Git Workflow Brief

Return this exact structure:

# 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
...

Why this is the safe path

Watch-outs

Recovery fallback

If this goes wrong, use ...

Adjacent handoff

Use code-review when ...
Use debugging when ...
Use task-planning when ...


### 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

git-workflow