How to Calculate Bus Factor From Git History
COUNT WHO YOU CAN'T LOSE
A concrete method for calculating bus factor from commits and reviews - not a survey, not a guess. What counts as ownership, and where the math lies.
TL;DR: Bus factor is computable. Weight each person's authorship per file from git history over a recent window, then greedily remove the top owner until more than half of an area's files have nobody left who knows them; the number of removals is your bus factor. Commit counts alone will mislead you. Reviews, squashes, and generated files all bend the math, and this article covers how to bend it back.
Ask a room "what's our bus factor?" and you'll get a survey of feelings. Ask git and you'll get an answer with receipts. The method below is the one the research uses, followed by an honest afternoon-sized version - and, because this is a metric people love to compute wrong, a list of the places the math lies. If you need the concept itself first, start with the pillar guide: what bus factor is and why it's usually worse than you think.
What counts as knowledge ownership?
Ownership is the ability to safely change an area without adult supervision, and git history is the best available proxy for it. Authorship is the strongest signal: people know code they wrote, especially code they created rather than edited. Reviewing is the second signal: someone who has repeatedly reviewed an area's changes can navigate and debug it, which is most of what you need when the original author is gone.
What does not count: being listed in a CODEOWNERS file (that's who should own it, not who does), having attended the architecture meeting, or "I looked at it once in 2023." Knowledge decays, which is why every serious method works on a recent window - 6 to 12 months - rather than all-time history that credits ghosts.
Why commit counts lie
Typing is not understanding, and git records typing. Raw commit or line counts overweight whoever ran the formatter, moved the files, regenerated the lockfile, or merged upstream, and underweight the person who landed twelve small, surgical fixes that each required deep context. Counting lines also rewards bloat and punishes deletion, which is exactly backwards.
The research fix is a degree of authorship (DOA) weighting. In the truck-factor literature - Avelino et al. (2016) is the standard reference - a developer's authorship of a file grows with: having created the file (worth a lot), each change they delivered to it (worth some), and shrinks as other people change it after them (recency and dilution both matter). Each file ends up with one or a few meaningful authors, not a raw tally.
How does the calculation actually work?
Three steps, mechanical enough to script:
- Score authorship per file. For every file (excluding vendored and generated paths), compute each person's weighted authorship from the window's history. Keep only the meaningful authors per file - the people above a threshold, not everyone who ever touched it.
- Greedily remove the biggest owner. Take the person who is a meaningful author of the most files and simulate their departure: every file where they were the only meaningful author is now orphaned.
- Repeat until the area breaks. Keep removing the next-largest owner until more than half of the files are orphaned. The number of people removed is the truck/bus factor. Avelino et al. ran exactly this against 133 popular GitHub systems, which is how we know 45 of them (34%) sat at a truck factor of 1.
Run it per area (service, package, top-level directory), not just globally. A healthy global number can hide a billing module that dies with one resignation; the per-area view is where the actionable list lives.
The honest afternoon version
You can get 80% of the value without implementing DOA. For each significant directory: pull the log for the last 12 months, count meaningful commits per author (skip merges, formatting, and generated files), and look at the shape. If one person has the overwhelming majority of meaningful commits and nobody else is close, that's a bus-factor-1 area; if two or three people show sustained activity, it survives a departure. While you're there, check the review side: if every PR into the area was approved by the same one person, your redundancy is thinner than the commit shape suggests.
Don't frame the single number on a wall. The output that matters is a ranked list: these areas have one meaningful owner, ordered by how much of the product stalls without them. That list is a work plan. The number is just its headline.
Where does the math lie?
Six places to check before you trust your result:
| Distortion | What it does | The fix |
|---|---|---|
| Squash merges | Credit collapses to whoever merged | Use PR authorship, not just committer fields |
| Generated files & lockfiles | Inflate whoever regenerates them | Exclude via path rules before scoring |
| Formatting / rename sweeps | One commit "owns" hundreds of files | Down-weight huge low-information commits |
| Reviewers invisible in history | Understates real redundancy | Count sustained review as fractional ownership |
| All-time windows | Credits people who left or forgot | Window to 6-12 months, decay older activity |
| Identity fragmentation | One human, three emails = three "owners" | Merge identities before computing anything |
None of these are exotic. Every one of them shows up in a real org's history, and each one quietly moves the number in the flattering direction. If your computed bus factor looks comfortable, audit the inputs before you celebrate.
What to do with the result
Fix the list, then keep the number honest by recomputing as the team and codebase move. Ownership drifts fast enough that a quarterly manual pass is the bare minimum, and a continuously computed ownership and bus-factor map is the version that doesn't rot. The single-owner areas you just found are also, almost by definition, your knowledge silos: here's how to hunt those systematically, including the review-pattern signals that pure authorship math misses.
The point of calculating bus factor was never the arithmetic. It's that "we should share knowledge more" becomes "these four areas each have one owner, this one is load-bearing, and the next PR into it gets a second reviewer." Vague risk becomes a to-do list - and to-do lists, unlike buses, are something an engineering team can actually drive.
Frequently asked
Can I calculate bus factor from commit counts alone?
You can, and it will lie to you. Raw commit counts overweight prolific committers, reformatting sprees, and generated files, and ignore reviewers entirely. Use a weighted authorship measure over a recent time window, and treat sustained reviewing as partial knowledge.
Do code reviewers count as owners?
Partially. Someone who has repeatedly reviewed changes in an area can usually navigate it, debug it, and safely change it; that's most of what ownership protects. A sane model counts sustained review activity as fractional ownership, not zero and not parity with authorship.
How often should bus factor be recalculated?
Continuously if it's automated, quarterly at minimum if it's manual. Ownership drifts fast: one reorg, one resignation, or one big refactor can flip an area from shared to single-owner in weeks. A stale bus-factor number is a false sense of security.
What time window should the calculation use?
Recent enough that the knowledge is still warm: 6 to 12 months of history is a sensible default. All-time history credits people who left years ago and engineers who no longer remember the code they wrote. Knowledge decays; the window should too.