You just joined a new team. Someone hands you a repo URL and says, "Get familiar with the codebase." What do you do?
Most developers start reading files from the top. They open src/, scroll through directories, and try to build a mental map folder by folder. That approach works—eventually—but it's slow, directionless, and leaves you guessing about the stuff that actually matters: where the problems live, who knows what, and whether the project is healthy or held together with duct tape.
Git has already been recording everything. Every bug fix, every refactor, every 3 AM hotfix—it's all sitting in the commit history, waiting to be read. You just need to know which questions to ask.
These five git commands take under two minutes to run and will tell you more about a codebase than a full day of browsing files.
1. Find the Files That Break Most Often
git log --name-only | grep -v "^$" | sort | uniq -c | sort -rn | head -20
This ranks files by how frequently they appear in commits—a list of churn hotspots. High-churn files are your biggest risk areas. A file changed 200 times in the last year is either core infrastructure (understandable but risky), a source of constant bugs, or badly designed with too many responsibilities.
When you see utils.js or helpers.rb at the top, it's usually a dumping ground for unrelated functionality that keeps getting dragged into every feature.
What to look for: Files appearing 5–10x more than the average. Configuration files that change frequently (environment instability). Test files with high churn (the code they test is unstable).
Action: Open the top 3–5 files and read them first. You'll get 80% of the codebase's context in 20% of the time.
2. Check the Bus Factor
git shortlog -sn
A ranked list of contributors by commit count—your project's bus factor. If one person has 80% of commits, that's your single point of failure. They're the only one who truly understands the system. If they leave, the team is in trouble.
A healthy project has 3–5 active contributors with a relatively even distribution. It should look like a hill, not a cliff.
Red flags: One contributor with >70% of commits. No commits in the last 30 days (abandoned or maintenance mode). Only junior developers committing (who's reviewing?).
What to do: If you see a bus factor of 1, learn from that person early. Pair program, ask questions, document what they know.
3. Map Where the Bugs Live
git log --grep="fix\|bug\|issue\|patch" --oneline | head -30
This filters commits that mention fixes, bugs, issues, or patches—a bug heatmap. Bugs don't distribute evenly. They cluster. A module with 15 bug-fix commits in the last quarter probably has deeper issues: unclear requirements, complex logic, poor test coverage, or all three.
How to read it: Look for patterns in file paths. Check if the same type of bug keeps recurring (null pointers, race conditions, off-by-one). Note time gaps—fixes clustered around releases are normal; scattered randomly suggests deeper issues.
Pro tip: Run with --stat to connect bugs to specific files:
git log --grep="fix\|bug" --stat --oneline | head -50
4. Read the Project's Pulse
git log --date=format:'%Y-%m' --format='%ad' | sort | uniq -c
Commit volume by month—an ECG for your project. Every project has a rhythm:
- Steady heartbeat — consistent commits. Healthy, sustainable.
- Spikes and valleys — feast or famine. Common in agencies and startups.
- Declining trend — fewer and fewer commits. Winding down or losing people.
- Sudden spikes — a month with 3x average usually means a deadline, hackathon, or emergency rewrite.
Big swings (50 commits one month, 500 the next) suggest crunch culture or poor planning.
5. Detect Firefighting Patterns
git log --grep="revert\|hotfix\|rollback\|emergency" --oneline
This catches rollbacks, hotfixes, and emergency patches—your deploy health indicator.
- A handful per year — healthy. The team deploys carefully.
- Every few weeks — deploy process is unreliable. Missing tests, staging doesn't mirror production, or rollbacks are harder than they should be.
- Weekly or more — firefighting mode. More time fixing production than building features.
Zero results is also a signal: The team might be genuinely stable, or nobody writes descriptive commit messages, or hotfixes are committed without labels.
The Bottom Line
| Command | What It Reveals | Time |
|---|---|---|
git log --name-only (sorted) | Churn hotspots | ~30s |
git shortlog -sn | Bus factor | ~5s |
git log --grep="fix\|bug" | Bug clusters | ~10s |
git log --date=format:'%Y-%m' | Project pulse | ~10s |
git log --grep="revert\|hotfix" | Deploy health | ~10s |
Total time: under two minutes. These commands won't tell you everything, but they'll tell you where to look first. That's the difference between spending your first day on a new codebase reading methodically—and spending it wandering.
📋 FAQ
Q: Do these commands work on any git repo? A: Yes—any repo with meaningful commit history. The more disciplined the commit messages, the better the signal.
Q: What if the team uses squash merges? A: The bus factor command may reflect who merged rather than who authored. Ask about merge strategy. The other commands remain useful regardless.
Q: How long does it take to run all five? A: Under two minutes for most repos. They only scan commit metadata, not file contents.
Q: Can I use these for code reviews? A: Absolutely. Running these before a review gives you context on high-risk files, domain experts, and bug history.
Inspired by "The Git Commands I Run Before Reading Any Code" by Ally Piechowski.