Git Intelligence in a Minute
Code Churn
What code churn measures in Git history, when it is useful, and why high churn is not automatically “bad engineering.”
In one sentence
Code churn measures how often lines or files are rewritten over a period—an activity signal, not a direct quality score.
Why it matters
Teams use churn to find hotspots, rework, and unstable areas. Misread as a productivity or quality grade, it punishes legitimate iteration and rewards untouched dead code.
How it works
- Common definitions count lines added and deleted in a window, sometimes excluding generated files or renames.
- File-level churn highlights paths that keep changing.
- Author or period comparisons describe activity concentration, not individual worth.
- Interpret churn with context: new feature spikes, incident fixes, and refactors all raise churn for different reasons.
Example
Rough file churn from Git (illustrative):
git log --since="30 days ago" --numstat --pretty=format: -- \
| awk '{ add+=$1; del+=$2 } END { print add+del }'Treat the number as “how much text moved,” then inspect which files and why before drawing conclusions.
What this proves
Churn proves that certain lines or files changed repeatedly (under your chosen definition and filters) in the measured window.
What this does not prove
High churn alone does not prove poor engineering quality, low skill, or wasted effort. Low churn does not prove stability or good design.
Last reviewed 2026-09-06. Title for citation: Git Intelligence in a Minute: Code Churn.