Most teams route code review by file path: src/auth/* goes to the security person, src/ui/* goes to the frontend person. It's a sensible system, and it has a blind spot: it assigns reviewers by domain, not by institutional knowledge.
The person who knows the auth module's history might not own it in the org chart. The person who owns it in the org chart might have joined three months ago. File-path routing can't see either of those facts.
I stopped relying on routing alone. Before a PR touches a load-bearing area, I look at one thing: the contributor graph for that area. The tool doing the counting is gitpulse for the whole repo, and git shortlog + git log for the slice, but the decision is what I want to write about.
The rule
When a PR touches a module I care about, the question is: who has the most commits in this module's history, and are they available to review?
Not "who owns this path in CODEOWNERS." Who has actually written it. Because the review question isn't "does this match the documented architecture?" — it's "does this match how the code actually evolved, and will it break the thing the author worked around in 2024?"
The second question can only be answered by the people who made the history.
How I get the number
Repo-wide, gitpulse gives me the contributor distribution in one command:
Top Contributors
A. Rivera ############################ 214
J. Chen ############# 87
M. Okafor ##### 34
L. Park ## 11
That's the census. For the module, it's a two-line git query:
git log --oneline -- src/auth | wc -l # how hot is it
git shortlog -sn -- src/auth # who built it
Cross-reference the two lists. The person with 214 commits repo-wide might have 3 in src/auth — they're not the auth person even though they're the biggest name on the graph. The person with 87 total might have 60 in src/auth and be the obvious reviewer even though they're "mid-level" on the org chart.
The three cases the graph reveals
1. The invisible owner. The module's biggest contributor is someone who's been quiet lately (a new role, a sabbatical, a departure that hasn't hit the org chart yet). The graph catches this before the PR sits unreviewed for a week. My response: find the second-biggest contributor in that module's history and route to them, and flag the ownership gap to the tech lead. The graph made the gap visible; the org chart had been lying by omission.
2. The concentrated risk. One person has 90% of a module's commits, and they're the PR author. Routing the review to "the other auth person" is weak — the other person has 4 commits there. I've learned to treat these PRs as higher-stakes: the review gets extra time, the reviewer gets the module's history as context (a git log --oneline -- src/auth | head -50 read), and I make sure the decision is documented, because the institutional knowledge is leaving with the author's next move.
3. The healthy spread. Three or four people each with 15-25% of a module's history is the gold standard. Reviews route naturally, knowledge is distributed, and bus factor is real. When I see this on a module, I route by recent activity (who touched it last) and move on — the graph tells me the system is robust, so I don't need to over-engineer the review.
Why not just ask "who knows this area?"
Because asking is slow and the answer is biased. People over-report their familiarity with areas they read and under-report areas they wrote but haven't touched in a year. The commit history doesn't over-report or under-report. It's the most honest "who actually knows this" signal you can get, and it's free.
The graph doesn't replace judgment — a senior reviewer with no history in a module can still be the right reviewer (breadth beats depth sometimes). But it replaces guessing, and it surfaces the two failure cases (invisible owner, concentrated risk) that guessing never catches.
The habit
It's a 30-second pass before I approve or route any PR that touches more than a few files:
-
gitpulsefor the repo's overall contributor shape (am I looking at a healthy team or a one-person show?) -
git shortlog -sn -- <path>for the module's actual builders - Route to the biggest available name in that slice, with the history as context
The tooling is small — gitpulse is a zero-dependency Node script that reads the local .git and prints the numbers, nothing uploaded. The value is in the decision it informs: review by history, not by org chart. The org chart tells you who's supposed to know the code. The graph tells you who does.
npx @wuchunjie/gitpulse
More Tools
| Tool | What it does | Command |
|---|---|---|
| scaffoldx-cli | Production-ready project templates in seconds | npx scaffoldx-cli |
| dotguard | Scan .env files for exposed secrets | npx @wuchunjie/dotguard |
| gitpulse | Git repo analytics in your terminal | npx @wuchunjie/gitpulse |
| snippetx | Terminal code snippet manager | npx @wuchunjie/snippetx |
If these save you time, consider buying me a coffee. All tools are MIT-licensed, zero-dependency, and run fully offline.
Top comments (0)