Git Branch Staleness Analyzer

{{ field.label }}:

{{ sourceField.label }}:

Check source data

{{ error }}

{{ header }}	Copy
No rows to export for the current input.
{{ cell.value }} {{ cell.value }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Git branch staleness is a cleanup signal for branches that have stopped moving, drifted away from their upstream, or lost the context that would make them easy to merge. A stale branch is not automatically bad. It may hold unfinished work, a release line, a hotfix path, or a protected default branch. The useful review asks whether the branch is still active, whether it contains work that has not reached the base branch, and who can safely decide its next state.

Branch cleanup matters because abandoned refs add noise to reviews, CI dashboards, release notes, branch pickers, and repository searches. They also create small but persistent risks: a developer can reopen old work against a changed base, a remote-tracking branch can disappear while a local name remains, and a half-finished pull request can look older or safer than it really is. A good cleanup pass separates low-risk merged branches from unmerged branches that need owner confirmation.

Flow diagram showing branch inventory moving through age and protection checks into a cleanup queue, ledger, and branch maps.

Age is only one input. A branch that is 90 days old and fully merged is different from a branch that is 90 days old, 12 commits ahead, and attached to an open pull request. Protected names such as main, release branches, and hotfix branches also need a different standard because deletion may be forbidden or operationally unsafe.

The safest branch cleanup review keeps evidence next to the recommendation. Last commit date, merge status, ahead and behind counts, upstream state, pull request marker, protected status, and author or owner all help turn a long branch list into a small set of owner follow-ups.

Technical Details:

Git branch inventory can describe three different facts that often get mixed together. The branch name identifies the ref. The last commit date gives an age against a chosen reference date. Upstream tracking shows whether the branch is ahead of, behind, equal to, or disconnected from its configured remote-tracking branch. Git's formatted ref output can report ahead and behind counts and can mark an upstream as gone when the tracked ref no longer exists.

Merged status is a reachability question. A branch marked merged is being treated as already integrated into the review target, while an unmerged branch may still contain commits that are not on the default branch. Hosted repository settings add another guard: protected branches can block deletion, force pushes, or direct updates depending on repository policy. That is why a cleanup review should never use age alone as a deletion rule.

Age is calculated in whole elapsed days. The reference date is the review date, and the last commit date is the branch's latest known commit timestamp. Rows with missing or unreadable dates are kept visible because they still need cleanup context.

age_days = floor (\frac{reference_date - last_commit_date}{86400000})

The classification rules are ordered. Once a branch matches an earlier condition, later conditions do not change that state. Boundary values are inclusive where shown.

Branch staleness classification rules
State	Rule used	Review meaning
Protected	The inventory marks the branch protected, the branch equals the default branch, or the name matches a protected term such as `release/*`.	Keep it out of deletion workflows and confirm the protection rule covers the intended name.
Merged	The row is marked merged. If a merged grace window is set and the branch age is below that window, the action becomes a hold instead of immediate cleanup.	Delete only after release, tag, or rollback checks are complete.
Unknown date	The last commit date is missing or cannot be parsed.	Add a last commit date before deciding whether the branch is stale.
Stale	`age_days >= stale_threshold`.	Ask the owner to delete, merge, rebase, or close the work with intent. Ahead commits and open review markers make deletion less safe.
Near stale	`age_days >= max(0, stale_threshold - near_stale_window)` and below the stale threshold.	Nudge the owner before the branch crosses the stale threshold.
Diverged	The branch is not already stale or near stale, has `ahead > 0`, and has `behind >= 10`.	Ask the owner to rebase, close, or clarify the branch before age becomes the main issue.
Current	No earlier rule matched.	No cleanup action is needed under the current thresholds.

Cleanup pressure is a 0 to 100 score used to sort the queue. It combines branch age, ahead commits, behind commits, classification state, open review markers, and gone upstream markers. Age contributes up to 58 points, ahead commits up to 24 points, behind commits up to 16 points, and state-specific weights add the rest before the score is clamped to 100.

Cleanup pressure components
Component	Maximum or weight	Effect on the review
Age share	Up to 58 points	Older branches rise toward the top, scaled by the selected stale threshold.
Ahead commits	Up to 24 points	Unmerged local work raises the pressure but also requires owner confirmation before deletion.
Behind commits	Up to 16 points	Branches far behind the upstream are more likely to need rebase or closure.
State weight	30 for stale, 16 for near stale, 14 for diverged, 18 for merged, 10 for unknown date	The classification can move a branch into the queue even when one numeric input is mild.
Open review marker	6 points	A listed pull request or review marker keeps owner review visible.
Gone upstream marker	12 points	A missing upstream raises cleanup urgency, especially when no ahead commits remain.

Accepted branch inventory can be a headered CSV, TSV, or pipe-delimited table with fields such as branch, last_commit, author, merged, ahead, behind, upstream, last_pr, and protected. Positional rows use that same order. Short git branch -vv style lines can provide branch and tracking context, but they usually do not carry last commit dates, so those rows need date enrichment before they can be aged reliably.

Everyday Use & Decision Guide:

Review one repository or branch group at a time. Enter a clear Repository label, confirm the Default branch, set the Reference date to the day of the cleanup review, and keep the default 45-day stale threshold unless your team already has a branch policy.

Paste a branch inventory with real dates whenever possible. A spreadsheet export or formatted git for-each-ref output is usually better than a plain branch list because age, ahead count, behind count, and upstream state can all change the recommendation. If you paste git branch -vv text without dates, expect the result to keep those branches visible as Unknown date until you add the last commit date.

Open Cleanup Brief first to see stale count, near-stale count, protected count, hidden merged branches, oldest branch, and highest pressure branch.
Use Branch Ledger for the full owner-facing review. It shows branch, last commit, age, author, tracking, state, and review note.
Work through Cleanup Queue when the summary says cleanup required or owner nudges. It ranks the branches that need action.
Use Branch Age Map to spot old branches against the stale rule and Ahead Behind Map to find branches that are drifting from their upstream.

Open Advanced when your cleanup policy has exceptions. Add protected branch terms for release and hotfix naming patterns, widen or narrow the near-stale window, and turn on Include merged branches only when you want already merged branches in the active ledger. The merged grace window is useful after releases because it can hold recently merged branches before deletion.

Do not treat a high cleanup pressure score as permission to delete. A branch with ahead commits, an open pull request marker, or an unknown date should move into owner follow-up, not straight into deletion. Before acting, compare Cleanup Queue with the repository host, recent pull requests, and any release or rollback rules your team uses.

Step-by-Step Guide:

Use a single branch inventory per run so the score and queue stay tied to one cleanup decision.

Set Repository to the service, repo, or branch group being reviewed. The label appears in Cleanup Brief and the JSON result.
Confirm Default branch. That branch is treated as protected even when the pasted inventory has no protected column.
Set Reference date, Stale threshold, and, if needed, Near-stale window. The age states update as those values change.
Add Protected branch terms for names that should not enter deletion workflows, such as release/* or hotfix/*.
Paste, browse, or drop the Branch inventory CSV. The source badge should show the number of branch rows parsed.
Use Normalize only to trim the pasted text into cleaner rows. If the page shows Paste at least one branch inventory row, restore the branch text before reading the result.
Read the summary badges, then open Cleanup Queue for owner follow-up and Branch Ledger for the full audit record.

If the warning area says rows have missing or unreadable last commit dates, fix those rows before using age-based states as cleanup evidence.

Interpreting Results:

The headline number is either stale branches or queued branches, depending on the current inventory. A stale count means at least one visible, unprotected branch reached the stale threshold. A queued count can include near-stale, diverged, merged, or unknown-date branches that still need a decision.

Cleanup required is stronger than owner nudges, but neither label proves deletion is safe. Check State, Tracking, Review note, and Owner before acting. A branch that is Stale and 0 ahead / 0 behind is a different case from a branch that is stale, 12 commits ahead, and attached to PR-301.

Protected rows should stay out of cleanup queues unless the repository's protection policy changes.
Merged rows can often be deleted after release and rollback checks, but the page hides them by default unless Include merged branches is on.
Unknown date rows are evidence gaps, not stale proof. Add last commit dates before making an age-based call.
Diverged rows are not old enough for the stale rule, but the ahead and behind counts make rebase or closure worth discussing.
Branch Age Map shows timing pressure. Ahead Behind Map shows sync pressure. Use both before asking an owner to delete work.

Worked Examples:

Old unmerged fix branch. A row for fix/legacy-route has last commit 2026-01-12, author Kumar, merged no, 1 ahead, 7 behind, and reference date 2026-05-01. With a 45-day stale threshold, Branch Ledger reports 109 days and state Stale. Cleanup Queue gives a pressure score around 96/100 and recommends owner confirmation because the branch still has an ahead commit.

Branch just below the stale threshold. A branch last committed on 2026-03-18 is 44 days old on 2026-05-01. With a 45-day stale threshold and 10-day near-stale window, it appears as Near stale, not Stale. The practical action is an owner nudge before the branch crosses the threshold.

Plain tracking output with no date. A pasted git branch -vv style line can expose a branch name and an upstream marker such as gone, but it may not include a last commit date. The row stays in Branch Ledger as Unknown date, and the warning area reports a missing or unreadable date. Add a date column from formatted ref output or a spreadsheet before using the cleanup queue as evidence.

FAQ:

Can I paste output from Git instead of building a spreadsheet?

Yes, if the rows include enough fields. Headered CSV, TSV, pipe-delimited rows, and positional rows work best. Short git branch -vv style rows can be parsed for branch and tracking context, but they usually need added dates for age analysis.

Why did a branch with a gone upstream get queued?

A gone upstream marker adds cleanup pressure because the tracked remote ref no longer appears to exist. If the branch has no ahead commits, it may be a local cleanup candidate after owner confirmation. If it has ahead commits, check intent first.

Why are merged branches missing from the main review?

Merged branches are hidden by default so the visible ledger focuses on active review work. Turn on Include merged branches in Advanced when you are auditing merged-branch deletion or grace-window behavior.

Does a stale branch mean it is safe to delete?

No. Stale means the branch age reached the selected threshold. Ahead commits, open review markers, release naming, protected status, and team rollback rules can all require owner review before deletion.

Are pasted branch inventories uploaded for analysis?

No server helper is used for the branch calculation. Pasted text and browsed CSV or TXT files are parsed in the browser, and copy, CSV, DOCX, chart image, and JSON exports happen only when you choose them.

Glossary:

Stale threshold: The age in days at which an unprotected, unmerged branch becomes Stale.
Near-stale window: The number of days before the stale threshold when owner nudges begin.
Upstream: The remote-tracking branch Git uses to compare ahead and behind commits.
Ahead commits: Commits on the branch that are not on the upstream branch.
Behind commits: Commits on the upstream branch that are not on the branch being reviewed.
Protected branch: A branch that should stay out of normal deletion workflows because of name, inventory flag, or repository policy.
Cleanup pressure: The 0 to 100 score used to sort branches that need cleanup review.
Merged grace window: An optional hold period before a merged branch enters cleanup action.

References:

git-for-each-ref documentation, Git project.
git-branch documentation, Git project.
About protected branches, GitHub Docs.
Deleting and restoring branches in a pull request, GitHub Docs.