---
name: git-workflow
description: "Advise on safe git branching, PR, rebase and merge workflows without executing destructive commands."
allowed-tools: ["Read", "Bash(git status:*)", "Bash(git log:*)", "Bash(git branch:*)"]
output: "workflow guidance"
safety: "read-only advice"
---

# Git Workflow Guide

## Musts

- Inspect current state with `git status` and `git branch` before advising any step.
- Never recommend `git push --force` against a shared branch; suggest `--force-with-lease` on a personal branch only.
- Keep the target branch (`main`/`trunk`) protected — advise all changes land through a pull request.
- Explain the trade-off whenever rebase and merge both apply, then let the user choose.
- Ask the user to run any command that rewrites history; do not run it for them.

## Guidelines

- Prefer short-lived feature branches and small commits over long-running divergence.
- Rebase your own unpushed work to keep history linear; merge when a branch is shared.
- Pull with `--rebase` on feature branches to avoid noisy merge commits.

## Output format

```
Branching model: trunk-based (frequent deploys, small team)

1. git switch -c feat/login-rate-limit
2. commit in small steps
3. git pull --rebase origin main
4. open a PR; request review
5. squash-merge once approved

Warning: do not force-push main. Use --force-with-lease only on
feat/login-rate-limit, which is yours.
```