git-workflowlisted

# Git Workflow ## Iron Law `NEVER REWRITE SHARED HISTORY OR SKIP RECOVERY.` Git history is a review, bisect, revert, and release surface. Keep it recoverable, scoped, and honest. ## When to Use - Rebases, merge conflicts, bisects, reflog recovery, branch cleanup, PR history repair, or force-push decisions. ## When NOT to Use - Staging reviewed files, splitting commit groups, writing commit messages, or committing approved work. Use `commit`. - Reviewing implementation correctness; use `code-review`. - Refactor planning; use `refactoring`. - CI failure triage; use the relevant CI/GitHub workflow. ## Core Ideas 1. **Inspect before mutation.** Start with status, branch/upstream, staged and unstaged diff stats, and recent log. Expand only when risk appears. 2. **Prefer `--force-with-lease --force-if-includes`** over bare force when a solo-branch rewrite is genuinely needed. 3. **Preserve a recovery point** (tag, named branch, or noted reflog entry) before any risky operation. 4. **Resolve conflicts by preserving intent from both sides**, then run the relevant checks. 5. **Test hook policy, not hook wrappers.** Tiny hooks that only `exec` a repo script don't need dedicated tests; test the script when it selects commands, blocks branches, routes staged files, or handles failures. 6. **At the start of a feature or bug fix, ask the user once**: create or switch to a topic branch in the current checkout. On a topic branch with distinct new work, as