What it measures

Commit Frequency counts how often code is committed across a repository, team, or individual over a defined window. It is typically expressed as commits per developer per day or per week, and it captures the cadence of writing and saving work to version control.

It is a raw activity signal. A high count means commits are landing often. A low count means they are landing rarely. The number says nothing about the size, content, or purpose of each commit.

How to measure it

Compute it directly from git history. Count commits in the target window using git log with author and date filters, then divide by the number of active contributors and the number of days or weeks in the window. Decide upfront whether to count merge commits, squashed commits, and bot commits, because each choice shifts the result.

Be deliberate about the unit of work. Teams that squash on merge will show far fewer commits than teams that merge every commit, even at identical output. Normalize by active contributor rather than headcount so that vacations, onboarding, and part-time work do not distort the average. For a fair cross-team view, align on a single squash and merge convention before comparing.

What it does not tell you

Commit Frequency measures motion, not direction. A developer can commit twenty times in a day on a dead-end branch, on whitespace and formatting, or on work that gets reverted next week, and the metric reads exactly the same as twenty commits that ship a critical feature. It rewards the habit of committing often, which is a personal or tooling choice, far more than it reflects the value of what was built.

It is also trivially gamed and easily misread. Splitting one change into ten commits inflates the number without adding output. Squashing ten commits into one deflates it without removing output. The metric tells you that hands are moving on keyboards. It does not tell you whether the work advances a strategic initiative, whether it is the right work, or whether anyone needed it done.

This is the gap Execution Intelligence closes. The question worth answering is not how many commits landed but what they were building and why. Reading the content of the work and tying it back to the initiative it serves is a different exercise from counting the cadence at which it arrives.

How InteliG uses it

InteliG computes Commit Frequency straight from real git and deployment history, with no manual instrumentation, agents, or developer surveys. It then treats the count as a starting point rather than a verdict, attaching each commit to the contributor who authored it and the initiative the work belongs to.

Cognis, the reasoning engine, connects that cadence to outcome and cost: which initiative the commits advance, who is carrying the work, and what that effort is costing relative to what it returns. The result is a read of what is being built and why, not just how fast it accumulates.

Related terms

Code Churn — How much code is rewritten or deleted shortly after being written
Pull Request Throughput — How many pull requests a team opens, reviews, and merges over time
Execution Intelligence — Reading how an organization actually executes, connecting code to strategy and cost