Five Git commands that tell you where damage is in the codebase before you even open a file. Brainstorm hotspots, bus factors, bug clusters and crisis patterns.
Eli Piechowski Read 4 minutes
The first thing I usually do when I pick up a new codebase is not open the code. This is opening a terminal and running some git commands. Even before I look at a single file, the commit history gives me a diagnostic picture of the project: who created it, where the problems are, whether the team is shipping with confidence or tiptoeing around land mines.
what changes the most
git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20
The 20 most changed files in the last year. The file at the top is almost always the one people warn me about. “Oh yes, that file. Everyone’s afraid to touch it.”
More churn on a file does not mean it is bad. Sometimes it’s just active development. But high churn on a file that no one wants to own is the clearest sign of codebase drag I know. This is the file where each change is a patch on a patch. The blast radius of a small edit is unpredictable. The team increases its estimate because they know it will counter-attack.
A 2005 Microsoft Research study found that churn-based metrics predicted defects more reliably than complexity metrics alone. I take the top 5 files from this list and cross-reference them against the bug hotspot command below. a file that is heavily churned And Hi-bugs are your biggest risk.
who built it
git shortlog -sn --no-merges
Each contributor is sorted by commit count. If one person’s stake is 60% or more, this is your bus factor. If they leave six months early, it’s a crisis. If the top contributor from the overall shortlog does not appear in the 6 month window (git shortlog -sn --no-merges --since="6 months ago"), I flag it to the customer immediately.
I also look towards the tail. Thirty contributors in the last year but only three active. The people who built this system are not the people who maintain it.
One caveat: the squash-merge workflow compresses authorship. If the team breaks each PR into a single commit, this output shows who did the merge, not who wrote it. It is worth asking about the merge strategy before drawing conclusions.
where insects gather
git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20
Same size as churn command, filtered with bug-related keywords. Compare this list with churn hotspots. The files visible on both are the code most at risk for you: they keep getting broken and patched, but never properly fixed.
This committed message depends on discipline. If the team writes “update content” for every commit, you will get nothing. But even a rough map of bug density is better than no map.
Is this project accelerating or decelerating?
git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c
Commit count by month, for the entire history of the repo. I scan the output looking for shapes. A steady rhythm is healthy. But what does it look like when the count is halved in a single month? Usually someone or the other went away. A period of decline over 6 to 12 months tells you that the team is losing momentum. Periodic increases after quiet months mean the team works in batches of releases rather than shipping continuously.
I once showed the CTO their commit velocity chart and he said, “That’s where we lost our second senior engineer.” They had not connected the timeline before. This is team data, not code data.
how many times is the team firing
git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'
Revert and hotfix frequency. A handful over a year is normal. Coming back every few weeks means the team doesn’t have confidence in their deployment process. They’re evidence of a deeper issue: unreliable testing, missing staging, or a deployed pipeline that makes rollbacks harder than they should be. Zero result is also a sign; Either the team is stable, or no one writes descriptive commit messages.
Crisis patterns are easy to read. Either they are there or they are not.
These five commands take a few minutes to run. They won’t tell you everything. But you’ll know which code to read first and what to look for when you get there. It’s the difference between spending your first day systematically reading the codebase and wandering around.
This is the first hour of what I do in codebase audit. The rest of the week looks like this.
Related Articles
<a href