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.
4. After the push, re-fetch the live heads and re-audit unresolved review threads, approvals, and checks. Commit hashes and inline-comment anchors from before the rewrite are not current evidence.