UK public sector / Ninety-one thousand branch names

16 August 2026 · method practice git

Nobody writes a branch name for an audience. Repository names get discussed, READMEs get reviewed, commit messages get squashed — but a branch is named in two seconds by one person who expects to delete it next week. That makes them the most honest artefact in the estate, and there are 90,831 of them here.

A third of them are robots

27,526 branch names — 30% — belong to dependabot, renovate and their relatives. That is the first thing to remove and the easiest to forget, and forgetting it does not merely add noise: it produces confident nonsense, which is a story on its own further down.

After excluding bots, and excluding forks, 56,629 branch names remain.

Ticket systems are visible from orbit

29% of human branch names begin with something shaped like a ticket reference, and there are 1,307 distinct keys across the estate. They are not evenly spread: almost every key belongs overwhelmingly to one organisation.

This is internal structure, published by accident and readable by anyone. DTSPO is HMCTS. DASD is the Skills Funding Agency's apprenticeship service. CB2 is DVSA. Nobody decided to publish a map of their Jira projects; it fell out of how branches get named.

HMRC alone shows seven distinct project keys in this sample. Not a criticism — it is a large organisation with many services. But it is a shape of the internal delivery structure that appears in no annual report, and it took one regular expression to see.

Naming discipline splits the estate almost exactly in half

47% of human branches are structured — either a prefix/ convention or a ticket reference. The rest are freeform: fix-thing, newstuff, test2.

The spread is wider than the estate average suggests, and it correlates with what you would guess: organisations running formal delivery against a ticket system sit at the top, research and platform teams at the bottom. Neither is wrong. A research group with six people and a shared whiteboard does not need feature/PROJ-1234, and a department with four hundred engineers cannot work without something like it.

Work that never landed

336 branches carry more than fifty commits that never reached the default branch and have not been touched since 2023. That is someone's fortnight, or month, sitting in public, finished or abandoned, with nothing to say which.

A related and stranger pattern: 419 repositories have a second branch still called master, main or develop which is ahead of the actual default and has not been touched in over a year. Those are repositories where the default branch was switched and the old one was left carrying commits that never came across.

The largest is a Department for Education repository whose master branch stopped in December 2019 holding 1,580 commits the current default has never seen. Whether that work matters is not something a branch name can say. That nobody has looked since 2019 is.

Three ways this was wrong first

Every number above survived a mistake, and the mistakes are more transferable than the findings.

The ticket ranking was mostly npm. The first pass produced LODASH, EXPRESS, MINIMIST and URLLIB3 as leading government project keys, because dependabot/npm_and_yarn/lodash-4.17.21 parses beautifully as ticket LODASH-4. Thirty-one percent of the corpus was robots and the regular expression could not tell.

The abandoned-work ranking was the Linux kernel. Sorting by commits ahead of the default put bbc/linux at the top with 106,996, followed by more of the same. It is a Raspberry Pi kernel fork: those commits are Linux, not abandoned BBC work. This project has written before about forks inflating committer counts by 72%, and the same trap was walked into again in a new measurement.

Half the orphans were alive. A develop branch ahead of main looked like a repository that had moved on and left work behind — until one of them turned out to have been touched that morning. That is gitflow working exactly as intended. Splitting on date moved 240 of them from "orphaned" to "deliberate", and without that split this post would have accused several teams of neglect for using a branching model.

Each of those produced a confident, plausible, entirely wrong answer. None of them threw an error. The only reason any was caught is that the result looked interesting enough to check, which is not a process.

What is not here

1,104 branch names matched security words — vulnerability, incident, CVE, and occasionally the specific defect under repair. A few of those sit on branches that have not merged, which means the name describes a problem that is plausibly still present.

Those are not in this post and will not be. Publishing "this repository has an unmerged branch named after the thing it is fixing" is a pointer rather than an analysis, and nothing above needs it. It is the same line drawn on the standards page about scanning for exposed .git directories: the measurement is legitimate, the index is not.

Method: from branch_recent in the harvest — the ten most recently touched non-default branches per repository, so this is a large sample of recent branches rather than a census. Bots and forked repositories are excluded throughout; where a figure would change materially without that exclusion, the post says so. Branch names are published by their authors as part of a public repository and no branch content was read. See Method.

← All writeups