What Your Git History Knows About Your Team

TL;DR: Your team has been keeping meticulous notes on itself for years: every change, every review, every timestamp, in version control. That log can answer the questions that actually matter: where knowledge sits in one head, how review really behaves, where work waits, how the codebase is aging. It cannot measure effort, difficulty, or who your best engineer is, and the honest analyst says so. Read it as a witness about the system, never as a scoreboard for the people, and it's the cheapest diagnostic instrument you own.

Every retro runs on memory and vibes. "Reviews feel slow." "Only Dana touches billing, right?" "We refactor plenty." Meanwhile, sitting in the corner, is a witness with perfect recall: the git history. Every change your team ever made, who made it, who reviewed it, when it landed, what it touched - timestamped, append-only, and already paid for.

Most orgs never depose the witness. This article is about what your git history can tell you, what it honestly can't, and the one rule that separates diagnosis from surveillance.

What the history can tell you

Where the knowledge lives

Authorship and review concentration per area is readable directly from the log, and it's the closest thing your org has to a map of where knowledge sits in one head. Avelino et al. (2016) built exactly this: a degree-of-authorship weighting computed from history, used to estimate truck factors for 133 popular GitHub systems. The result - 45 of them, 34%, at a truck factor of exactly 1 - came from reading repos, not surveying teams. The same reading, on your repo, is the bus-factor calculation, the knowledge-silo map, and the early-warning system for the legacy system with one living interpreter. One honest caveat, covered in depth in the code ownership discussion: last-touch is not ownership, so the weighting matters. Blame-line counting crowns whoever ran the formatter.

How review actually behaves

Forget how the review policy reads; what matters is how review behaves. Pickup times, approval patterns, who carries the load, which merges nobody meaningfully looked at. This is measurable at any scale; Sadowski et al. mined roughly 9 million reviewed changes at Google and could state the system's actual behavior: median reviewer response under 4 hours, small changes getting first feedback within an hour, a median of one approver per change. Your history supports the same deposition, and pickup time and review coverage are queries you can run today.

Where the work waits

Timestamps chain into a flow record: commit to PR, PR to pickup, pickup to merge. The gaps between them are where your cycle time actually goes, and they're attributable to specific queues - which is how "everything feels slow" becomes "PRs in this area wait three days for one overloaded reviewer."

How the codebase itself is aging

History also records the code's own behavior over time. Duplication, churn, rework, refactoring share: all derivable from diffs at scale. GitClear's 2026 study read 623 million code changes and could document the AI-era shift in hard numbers: code-block duplication up 81%, the share of commits that move (refactor) code collapsing from 21% to 3.8%. That's the kind of trend - invisible in any standup - that only the accumulated history can show. On your own repo, the same lens answers how much of the code is AI-written and whether the cleanup work is actually happening.

What the history honestly can't tell you

A witness this good deserves honest limits. Git history records artifacts. It does not record:

• Effort or difficulty. The three-line fix that took a week of investigation looks identical to a typo correction.
• The whys. History shows what changed. The reasoning lives in decision records and tribal-knowledge capture, or nowhere.
• The invisible work. Mentoring, unblocking, and the incident prevented by a careful review. None of it commits.
• Who your "best" engineer is. Line counts reward verbosity and punish the person who deleted complexity; commit counts mostly measure batch-size habits. Any tool that turns history into a developer ranking is selling you a number the data cannot support. The full argument lives in individual developer performance metrics.

The rule: depose the system, not the people

The same log answers two kinds of questions. "Which areas depend on one head, and how critical are they?" is a system question. Its answer indicts routing and review policy, and it produces fixes: rotation, a named successor, a rebalanced queue. "Who's my least productive developer?" is a people question the data can't answer, asked of a witness who never saw the crime. Teams can smell the difference immediately. Analysis that grades people gets gamed by lunchtime; analysis that fixes systems gets adopted.

So the operating rule: every query of the history should end in a change to the system - a routing change, a policy change, a succession plan, a better-run offboarding. If a query can only end in a verdict on a person, it wasn't a diagnostic. It was a performance review wearing a lab coat.

Start reading

You can depose the witness manually - git log, an afternoon, one area you're worried about - and for a single question, you should. What a manual pass can't give you is continuity: concentration drifts, review load shifts, and the trend is the signal. Reading that log continuously, with honest authorship weighting and review data joined in, is literally what Busfactor is: a standing deposition of your git history, asking only the system-shaped questions. The notes have been taken for years. Someone should finally read them.