Also called Churn rate (software), Code volatility, Change frequency
In depth Code churn: what it is, how to measure it and what it predicts: git commands that run, the research behind churn, and why it fails as a productivity metric.
How code churn is measured
Churn has two common definitions. Line churn is lines added plus lines deleted. Commit churn is the number of commits that touched the file. Both come from git log, and both need a window (30, 90 or 180 days) to mean anything.
A worked example for api/orders.py over 90 days:
| Commit | Lines added | Lines deleted | Churn |
|---|---|---|---|
| a1 | 40 | 10 | 50 |
| b2 | 5 | 5 | 10 |
| c3 | 120 | 80 | 200 |
Line churn is 260 and commit churn is 3. If the file is 400 lines long today, relative churn is 260 / 400 = 0.65. A modified line counts as one deletion plus one addition, so editing 10 lines is 20 churn. Merge commits are usually excluded so the same change is not counted twice.
Why code churn matters
Churn points at the files where change keeps landing. Repeated change means repeated review, repeated testing and more chances to break something. The research favours the relative version: Nagappan and Ball, "Use of Relative Code Churn Measures to Predict System Defect Density" (ICSE 2005), studied Windows Server 2003 and reported that relative churn measures predicted defect density well while absolute churn did not.
Churn is a weak measure of developer productivity. Formatting, renames, generated files and refactors all raise it without adding features. Read it as a map of activity, then combine it with cyclomatic complexity to find a code hotspot.
How to measure code churn yourself
Git alone is enough:
# Added and deleted lines per file over 90 days, summed and ranked by total churn
git log --since="90 days ago" --no-merges --numstat --pretty=format: \
| awk 'NF==3 {c[$3]+=$1+$2} END {for (f in c) print c[f], f}' \
| sort -rn | head -20Binary files print - instead of numbers and add nothing to the sum. Renames print as old => new and can split a file's history, so check moved files by hand. Exclude lockfiles and generated code with pathspecs. For commit counts only, git log --name-only --pretty=format: piped through sort | uniq -c is enough. The linked guide covers these edge cases in detail.
How repowise measures code churn
repowise reads git log --numstat per file when it indexes (the last 5,000 commits by default) and stores, per file:
- Commits in the last 30 and 90 days, lines added and deleted in the last 90 days, and the average lines changed per commit.
- A recency-weighted churn score: each commit contributes its lines changed divided by 100, capped at 3, and its weight halves every 180 days. Last week's commit counts far more than one from a year ago.
- A churn percentile: the file's rank by that score among the repository's code files. Files in the top quartile that also clear minimum activity floors are flagged as hotspots (see code hotspot).
You see these on the Hotspots page of the dashboard, in get_context and get_risk over MCP, and with repowise risk --target <file>. They come from git only, with no model involved, so the same history gives the same numbers. See git intelligence.