Search tldr

The Git Commands I Run Before Reading Any Code

Five Git history queries provide a fast risk map for an unfamiliar codebase: churn hotspots, concentrated ownership, recurring bug locations, delivery momentum, and firefighting patterns.

Share

The Git Commands I Run Before Reading Any Code

Author: Ally Piechowski | Published: 2026-04-08 | Generated: 2026-04-08 | Domain: piechowski.io
Tags: ‘#git’ ‘#codebase-audit’ ‘#technical-debt’ ‘#legacy-code’ ‘#engineering’


TLDR

Before opening source files in a new codebase, inspect Git history to identify where change, defects, ownership risk, delivery slowdowns, and operational crises concentrate. The five commands are deliberately lightweight diagnostics rather than definitive measurements: cross-reference churn with bug-related commits, account for workflow artifacts such as squash merges, and validate patterns with the team. Used together, they prioritize what code to inspect first and expose organizational risks that code alone cannot show.

Key Takeaways

  • Find churn hotspots first: git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20 lists frequently changed files; run it from app/ or src/ to avoid lockfiles, generated files, and changelogs dominating results.
  • Combine churn with defect signals: Absolute churn alone is a weak predictor of defects; a 2005 Microsoft Research study found that churn normalized by component size predicts defect density better. Files ranking highly for both churn and bug-related commits are the largest risks.
  • Assess ownership and bus factor: git shortlog -sn --no-merges ranks contributors by commit count. One person responsible for 60%+ of commits, particularly if inactive or departed, represents a serious knowledge-concentration risk; squash merges can make this measure reflect merger rather than author.
  • Map bug-prone files: git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20 surfaces files repeatedly touched in bug-fix commits, though its usefulness depends on descriptive commit messages.
  • Read team health in history: Monthly commit counts reveal steady delivery, abrupt staff-loss effects, long-term momentum decline, or batch-release cycles. Frequent revert, hotfix, emergency, or rollback commits may signal unreliable tests, inadequate staging, or difficult deployment rollbacks.

Images & Media

Keep reading