Git Intelligence: Hotspots, Bus Factor & Hidden Coupling, Explained

Why does git intelligence matter?

Your code tells you what it does. Only your history tells you how it behaves: where bugs keep landing, who is the only person who understands a module, and which files quietly change together.

The riskiest files are where churn meets complexity — and the knowledge often lives in one head. A linter sees neither.

• A file that is complex but never changes is rarely worth refactoring; a file that is complex and changes constantly is where defects cluster.
• When one author owns over 80% of a file, their departure is an outage you did not schedule.
• Two files that always change together — with no code link between them — are a coupling no dependency graph will warn you about.

How does git intelligence work?

repowise reads your last 500 commits (configurable up to 5,000) plus git blame, parses the repo into a dependency graph, and derives every signal deterministically — no LLM in the path, the same history always producing the same result.

1. Read history. git log and git blame are parsed and the repo is built into a dependency graph. No code leaves your infrastructure.

2. Derive signals. Churn, complexity, co-change pairs, and per-file ownership are computed deterministically — empirically the signals stabilize around 300–500 commits.

3. Rank risk. Hotspots and bus-factor files are ranked and rolled up per module, then surfaced in the dashboard, on PRs, and over MCP.

How does git intelligence help you?

The four signals are not a dashboard you admire. repowise turns each into an action you take the same day.

Hotspots — target refactoring where it pays

A hotspot is a file in the top 25% of both churn and complexity — not either alone. That joint filter is what keeps you from drowning in every complex file you never touch.

Guardrail: a hotspot is a ranking signal, not an auto-refactor — repowise ranks and explains, it never rewrites your code.

• Churn comes from git history, complexity from the parsed code; the composite risk score blends them.
• The riskiest files surface first, recomputed on every commit, deterministically.
• The same churn × complexity view powers the dashboard, the Repowise PR Bot, and get_risk over MCP.

Bus factor — de-risk offboarding before it is a fire

bus_factor: 1 means a single author owns over 80% of a file's history. repowise attributes lines to contributors from git blame, names the primary owner, and flags key-person risk.

Guardrail: this reads commits, it does not watch people — no IDE plugins, no instrumentation, no surveillance.

• Primary owner, recent owner, and contributor count per file.
• The bus-factor warning surfaces in the ownership view and in CLAUDE.md.
• Works retroactively on the history you already have — nothing to instrument going forward.

Change coupling — find the dependencies your graph never sees

Hidden coupling is a pair of files that repeatedly change together in the same commits without an import edge between them. AST analysis cannot detect it; git history reveals it.

• Co-change partners are mined from commit history, per file.
• They surface in get_context alongside direct dependencies.
• get_risk flags a missing historical partner on the PR blast radius, so the omission is caught in review.

Heritage — read a file's age and evolution

Code heritage shows how old each file is and how it has evolved — first appearance, change magnitude over the last 90 days, and a churn trend (increasing / decreasing / stable from the 30-day versus 60-day rate).

• The change pattern is classified: feature-active, fix-heavy, primarily refactored, dependency-churn, or mixed-activity.
• Change magnitude tracks lines added/deleted and average commit size over the last 90 days.
• The last meaningful commit messages per file inform why it is shaped the way it is.

Walkthrough: three views in five minutes

Step 1 — Open hotspots. The riskiest files sit at the top. Each row shows churn percentile, complexity, and the composite risk score that blends them.

Step 2 — Open ownership. Filter to bus_factor: 1 to find the files most exposed if one person leaves. The owners view rolls the same git-blame data up per contributor — who carries which part of the codebase.

Step 3 — Open change coupling. Each pair shows how many commits the two files moved together in. High counts with no import edge are the ones to investigate before your next change.

Proof: deterministic signals, straight from your history

Each stat stands alone and is reproducible on your own repo — every signal is open source under AGPL-3.0.

The engineering case for why these process metrics outpredict structural metrics alone lives in process metrics beat structural metrics.

Try it on your repo

See where the risk and knowledge concentrate in your repo — deterministic, self-hosted, straight from your history.

pip install repowise
repowise init                          # reads 500 commits + git blame
repowise init --commit-limit 5000      # deepen the history window

The same numbers are reachable by AI agents via the get_risk and get_context MCP tools.