pr-history-hygienelisted

# PR History Hygiene Discipline for the lifecycle of a pull request, from preparation through landing. It covers how to split work, how to rewrite history safely, how to label, and how to land a stack of dependent PRs. It applies to any git workflow with pull requests; the platform-specific bits (stacking, labels) generalize to whatever the repo uses. **The defining constraint:** history is rewritten only when it is **lease-protected** — a force-push that aborts if the remote has moved — and never with raw force. Everything else follows from protecting other people's work and the review record. ## Choose the history deliberately - **Split independent changes.** Each PR is one coherent change; do not bundle unrelated work. When a bug is found in a PR you already published, fix the introducing PR before propagating the fix to dependents. - **Pick the merge strategy per change.** After review, an ordinary branch may merge forward or rebase. A history rewrite is allowed after review, but it invalidates every commit-OID assumption — re-audit review threads, approvals, mergeability, and checks afterward. ## Rewrite safely — never raw force Before any history rewrite: 1. Fetch the current remote branch and record its exact head. 2. Publish with a **lease-protected force-push** (e.g. `--force-with-lease=<branch>:<observed-head>`) so a concurrent update aborts the push instead of being overwritten. 3. **Raw `--force` is never allowed** — it silently destroys a concurrent update