Every repository accumulates them: hundreds of refs, most of them merged long ago, a handful carrying work nobody remembers. Producing the list is a one-liner. Acting on it is where the damage happens, because the property that makes a branch safe to delete is not the one the list is usually sorted by.
Open the free branch hygiene scanner
A branch untouched for a year whose commits are all reachable from the default branch is free to delete — the work is in main, and the ref is a label on history that exists anyway. A branch untouched for a year that carries commits reachable from nowhere else is the opposite: deleting the ref is the only thing keeping those commits addressable, and once the reflog expires they are gone in a way no amount of searching recovers.
Both branches look identical in a list sorted by last commit date. Sorting by "stale" is therefore sorting by the wrong column.
| Classification | What it means |
|---|---|
| Merged into the default branch | Nothing unique is lost. The cheap case. |
| Carries unmerged commits | Deleting drops the only reference to real work. Read it before deciding. |
| Ambiguous or malformed ref | Fail closed. An unresolved ref is not a safe deletion. |
For every branch you intend to delete, record the name, the tip commit SHA, the last commit date, and the classification that justified it — before the deletion, not as a note afterwards. Recovering a branch is trivial while someone still holds its tip SHA and effectively impossible once nobody wrote it down. The manifest costs one command and is the whole difference between an undo and an incident.
The scanner is read-only on purpose. It turns a portable snapshot into a report, a recovery manifest, and — for spreadsheet or ticket-based review — an approval-queue CSV of branch metadata and a review action per row. The export deliberately contains no shell commands: it cannot approve a deletion and it cannot perform one. For a scheduled or CI review it emits a stable JSON summary and can fail closed when the snapshot contains an ambiguous ref, so an unclear case stops the run rather than passing quietly.
It is cheap to delete a branch whose commits are already reachable from the default branch, because nothing is lost — the work is in main. It is not safe to delete a branch that carries commits reachable from nowhere else, however old or inactive it looks, because deleting the ref makes those commits unreferenced and eventually collectable. Age and inactivity say nothing about whether unique work exists; only reachability does, so classify on that and record the tip SHA of anything you delete.
A recovery manifest: for every branch you intend to delete, its name, its tip commit SHA, its last commit date, and the classification that justified the deletion. Recovering a deleted branch is trivial while you still hold the SHA and effectively impossible once nobody wrote it down and the reflog has expired. The manifest costs nothing to produce and is the difference between an undo and an incident.
No, deliberately. It reads a snapshot you supply and emits a report, a recovery manifest, and optionally an approval-queue CSV containing branch metadata and a review instruction. It never contains a shell command, cannot approve a deletion, and cannot perform one. Deletion stays a decision a person makes with the report in front of them.