What Is Commit Velocity?

Commit velocity is the rate at which a startup's engineers commit code to public repositories, usually measured in commits per week. It is one of the few leading indicators of startup traction you can read for free, and it has historically risen 3 to 6 weeks before a fundraise is announced. This guide is the definitive reference: what commit velocity is, how to calculate and read it yourself on GitHub, what it can and cannot prove, and how to fold it into a real sourcing and diligence process.

What commit velocity actually measures

Commit velocity counts how frequently a team pushes code to its public repositories. A team shipping daily commits far more often than one that pushes once a month, and that difference shows up immediately in the commit graph. The raw number is noisy, so the useful form is the trend over time: is velocity rising, flat, or falling across 4 to 12 weeks?

Velocity is a proxy for execution, not for code quality. A team that ships constantly is answering the question investors care about most at the earliest stages: can this team actually build and iterate? When revenue and product-market fit are unproven, shipping speed is one of the best available signals of execution capacity.

Three nuances matter from the start. First, velocity is a rate, not a total: commits per unit of time, not lifetime commits. Second, it is a team property, not a single author's: a healthy velocity is spread across contributors, not concentrated in one founder. Third, it is only meaningful as a trend: a single week is a snapshot, and snapshots mislead.

How to calculate commit velocity

The mechanics are simple enough to do by hand. Pick a repository, count the commits in each of the last 12 weeks, and plot them. Then smooth the noise with a rolling 4-week average. The signal you read is the slope of that smoothed line, not any individual point.

A worked example, using a clearly hypothetical repository:

• Week 1 to 4: 8, 9, 10, 9 commits, a 4-week average of 9.
• Week 5 to 8: 12, 14, 15, 16 commits, a 4-week average of roughly 14.
• Week 9 to 12: 20, 22, 24, 25 commits, a 4-week average of roughly 23.

That trajectory, from a 9 average to a 23 average over a quarter, is a breakout. A single 25-commit week with no surrounding trend is not. The slope over 8 to 12 weeks is the signal; the rest is noise.

You do not need to do this arithmetic yourself. GitDealFlow computes velocity weekly across 350+ startups and normalizes it by sector, so the breakout shows up as a comparable momentum score rather than a raw count you have to interpret by hand.

Why commit velocity predicts fundraising

The pattern is causal, not just correlational. When a startup prepares to raise, it accelerates. Founders push to ship the roadmap items they will demo, engineers race to close the gaps diligence will expose, and the team front-loads work before the distraction of a fundraise process absorbs everyone's attention.

That acceleration shows up in public GitHub activity before it shows up anywhere else. A round announcement, a press hit, or a Crunchbase entry is a lagging indicator; the commit spike that preceded it is the leading indicator. GitDealFlow's published methodology (SSRN abstract 6606558, CC BY 4.0) documents this lead time across a research panel of 219 startup-period observations, with signals typically appearing 21 to 47 days before the round hits the press.

The mechanism is intuitive once you see it: fundraising compresses the roadmap, and a compressed roadmap looks like a velocity spike in the commit graph. It is not that founders fabricate activity; it is that the weeks before a raise are genuinely the busiest weeks a team has.

How to read commit velocity on GitHub yourself

You can verify any velocity claim in a few minutes without any special tooling. On any public repository, open the Insights tab and look at two views:

• Contributors: shows commits per author over time, which reveals both the pace and the concentration of the work.
• Pulse: shows the recent activity summary, including how many commits, pull requests, and issues changed in the last week and month.

The Contributors view is the more useful of the two for velocity. Look at the trailing 4-week bars for each author: is the total rising across the team, and is the work spread across multiple people? A rising total spread across a growing team is the healthy pattern.

For a whole organization rather than a single repo, the process is the same but slower: visit each active repository and read its Contributors graph. This is exactly the aggregation GitDealFlow automates, because doing it by hand across a portfolio of dozens of companies is not sustainable.

What commit velocity does NOT tell you

Commit velocity has real limits, and a good investor holds all of them in mind:

• It can be gamed: teams can inflate commits with trivial changes. Sustained velocity over months is hard to fake, but single-week spikes are not evidence of anything.
• It is blind to private work: a team that moved development to private repositories or internal tools disappears from the public signal.
• It says nothing about quality: shipping fast and shipping well are different. Velocity is an execution signal, not a code-quality audit.
• It is sector-dependent: a developer-tools team commits differently from a fintech or biotech team, so raw counts are not comparable across sectors.

This is why commit velocity should never be used alone. The strongest readings combine velocity with contributor growth and repository expansion, the other two signals GitDealFlow tracks, and then cross-check against qualitative diligence.

Commit velocity vs other GitHub signals

GitHub exposes several public signals, and they mean different things. Stars and forks measure popularity, not shipping. A repository can accumulate stars while development stalls, and a heavily-forked repo can be abandoned. Stars tell you what other developers found interesting; they say little about whether the team is still building.

Contributor growth measures team expansion, repository creation measures direction, and commit velocity measures pace. Of the three, velocity is the most direct execution signal, but it is most valuable when all three move together: a team that is shipping faster, with a growing team, into new product areas.

Common misconceptions about commit velocity

Three misconceptions come up constantly. The first is that more commits always means a better team; it does not, because commit quality and product relevance matter more than raw count. The second is that a low public commit count means a slow team; it may just mean private repositories or a different workflow. The third is that velocity is a ranking score; it is a trend you read in context, not a number you compare in isolation.

Each misconception traces to the same error: treating velocity as an absolute metric rather than a relative, contextual signal. Velocity is meaningful as a slope over time, normalized within sector, and read alongside contributor growth and repository expansion. Strip away that context and the number misleads.

Using commit velocity in your process

Investors use commit velocity in three places. In sourcing, it finds teams whose velocity just broke out before the market notices. In screening, it quickly ranks a long list of candidates by execution evidence. In diligence, it confirms that a founder's claims about momentum match the public record.

The weekly GitDealFlow digest surfaces the five startups with the strongest velocity breakouts each Sunday, so the signal arrives pre-packaged rather than requiring you to run the numbers yourself. Start with the free digest, then graduate to a watchlist with alerts as your process matures.

Start tracking for free →