Code Ownership and Bus Factor: Mining Git History for Team Risk

To measure code ownership and bus factor, count each author's share of a file's commits (or surviving lines) and find how few authors cover 80% of them. If one person covers it, the file's bus factor is 1. git shortlog and git-fame give you the raw counts; repowise init computes owner, recent owner and bus factor for every file at once and flags the files where the knowledge is at risk.

Part of the Git Intelligence guide.

What is bus factor?

Bus factor (also called truck factor) is the smallest number of people who would have to leave before a project or file has nobody left who understands it. A bus factor of 1 means a single departure strands the code. It is a per-file and per-module property: a repository can look healthy overall while its billing module depends on one engineer.

Low bus factor shows up as review bottlenecks (only one person can approve changes to a module), fear of touching code whose author left, and slow onboarding because the design lives in a few heads. The data to find it is already in your version control history.

Quick answer: which tool for which question

CODEOWNERS answers a different question from the others. It records who is assigned to review a path, while git history records who actually wrote it. The two are worth comparing: a CODEOWNERS entry for someone who has not committed in a year is a quiet signal of lost knowledge.

Step 1: Count authors from git

git shortlog is the fastest first look. It groups commits by author, and scoping it to a path gives a per-file or per-directory view.

git shortlog -sn --no-merges -- src/payments/

   212  Dana Lee
    19  Sam Ortiz
     4  Priya Nair

Here Dana wrote 90% of the commits to src/payments/. That is a bus factor of 1 by the 80% rule below. Pass --since="90 days ago" to see who is active now rather than who wrote the original code.

Why git blame misleads

git blame credits each line to the last commit that touched it. A formatter run or a rename across the codebase moves a whole file to whoever ran it. Commit counts and the share of lines that still survive from each author are steadier signals. Add -w and -M to blame to ignore whitespace and detect moved lines, and use a .mailmap so one person with several email addresses is counted once.

Step 2: Turn counts into a bus factor

A practical definition: the bus factor of a file is how many of its top authors it takes to cover 80% of its commits. If one author covers 80% or more, it is 1. If it takes two, it is 2. A file with no history has no bus factor, which is not the same as no risk.

Two refinements matter more than the formula:

• Recency. A bus factor of 1 on a file nobody edits is low risk. The dangerous case is a file that is still changing while its main author has gone quiet, because people are now editing around intent they cannot see.
• Who is active. An original author who has not touched a module in 18 months remembers the intent, rarely the details. Compare the all-time owner with the owner of the last 90 days.

Step 3: Run it on the whole repository with repowise

repowise init computes ownership for every file from git log and git blame during indexing. It needs no LLM key and makes no network calls. Ownership is computed with the rest of the git intelligence signals.

uv tool install repowise      # or pipx / pip install repowise
repowise init                 # ownership is computed during indexing
repowise risk --target src/payments/processor.py

For each file, repowise records:

Author names pass through .mailmap, and GitHub noreply addresses for one login are folded together. Commits that only move a file do not count as authoring it. --follow-renames keeps ownership across file moves, and --commit-limit N sets how many commits per file are read (default 500, maximum 10000).

Module silos and the truck factor

Per module (top-level directory), the owner is whoever owns the most files in it. A module is a silo when one person owns more than 80% of its files. Across the repository, the truck factor is the fewest primary owners who together own more than half the files, with bot authors left out. The dashboard Owners page lists contributors and per-person profiles: the files and hotspots they own, the modules where they hold more than 80%, and the bus-factor-1 files only they own.

The repowise hotspots view for the repowise repository, ranking files by commits, fixes and churn with bus factor and owner columns and a bus factor risk filter

The hotspots view puts bus factor next to churn and bug-fix counts, which is the combination that matters: a file that changes constantly and that one person understands is where a departure hurts most.

The three ownership detectors

repowise turns these fields into findings that appear in repowise health and the dashboard's code health view.

On a small team (3 or fewer active contributors in 90 days), one owner per file is normal. These findings are capped at low severity there unless the file is a hotspot, and the small-team profile in .repowise/health-rules.json lowers them further.

Step 4: Ask from your editor or agent

Ownership is available to an AI agent through the same data the CLI uses. With ten MCP tools, three cover this topic:

get_context(targets=["src/payments/processor.py"], include=["ownership"])
get_risk(changed_files=["src/api/routes.ts", "src/middleware/cors.ts"])
get_overview(include=["ownership"])

get_context returns the ownership block:

"ownership": {
  "primary_owner": "Dana Lee",
  "owner_pct": 0.71,
  "owner_line_pct": 0.83,
  "contributor_count": 4,
  "bus_factor": 1,
  "recent_owner": "Sam Ortiz",
  "recent_owner_pct": 0.6
}

In PR mode, get_risk lists up to five recommended reviewers for the changed files, ranked by how many of those files they own. get_overview returns the repository's average bus factor and the count of bus-factor-1 files. An agent can use this to tell you, before an edit, that the file has one knowledgeable owner and to suggest that person as a reviewer.

What to do about a bus factor of 1

Fix the files that are both risky and active first. Use the hotspot view to rank, not the whole list.

• Assign a second author, not a presentation. Give someone with no history in the module a small real change. Commits transfer knowledge better than a walkthrough.
• Rotate reviewers. Add someone who does not know the module as a second reviewer next to the expert, so the context is written into the PR thread. The reviewer list from get_risk shows who the experts are.
• Pair on hotspots. For files with high churn and high complexity, have two people present for design decisions.
• Write down the why. Where a second author is not possible, record decisions and generate documentation for the module. repowise keeps decisions and docs next to the code they explain.
• Reconcile CODEOWNERS with history. Remove or add owners where the file's recent authors differ from the listed ones.

A healthy module usually has a clear lead and two or three other people with real commits. One author at 95% is a silo; many authors with tiny shares and no one above 40% is a module without direction.

Pitfalls

• Ownership is authorship, not responsibility. Someone who reviews every change but never commits does not appear in git history. Owner means "wrote the most", not "is accountable".
• Squash merges credit one author. The whole change goes to whoever is recorded as the commit author, and Co-authored-by trailers do not count toward ownership.
• Shallow clones hide history. A shallow clone sees only the commits it fetched, so owners describe that window. Run git fetch --unshallow before indexing.
• A bus factor of 0 is missing data. It means no history was indexed for the file.
• Bulk reformatting inflates one person. Prefer commit share and surviving lines to last-touch blame, and keep formatter commits out with git blame --ignore-revs-file.