Git Workflow

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:

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

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:

1. branch-and-stage hygiene — branch creation/switching, staging, stash-or-clean decisions
2. commit-shaping — amend, fixup, reword, interactive rebase, cleaner review units
3. sync-with-base — fetch + merge/rebase choice when the branch must catch up
4. conflict-resolution — merge/rebase already produced conflicts; the next safe loop matters most
5. push-safety — upstream setup, rejected pushes, diverged branches, rewrite-safe pushes
6. 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