Quick Answer: Git-based time tracking estimates how long you spent coding by reading your commit history instead of running a timer or installing a per-editor plugin. It works by grouping commits into sessions from their timestamps, which gives you a fast, zero-setup picture of when you worked and roughly how much. It is the best free way to get the shape of your effort, but commit data alone is a benchmark rather than an accurate clock, especially when AI writes a lot of your code. Use it for a quick baseline, and add lightweight telemetry when the hours have to be defensible.
If you have ever wanted your coding hours without babysitting a stopwatch, this is the category you are looking for. Git already records when every commit landed, so the appeal is obvious: the data exists, it costs nothing, and you do not have to remember to start anything. The catch is everything that happened between the commits, which we will get to.
What git-based time tracking is
Most developers find this approach the same way: a client asks how long a feature took, or you want your own weekly hours, and the idea of installing yet another tracker feels like overkill. Git-based time tracking reads the timestamps that are already in your repository and turns them into time.
A commit stores an author date down to the second. That single fact is the whole foundation of the category. A git-based tracker sorts your commits, looks at the gaps between them, and decides which commits belong to the same working session. The output is a set of sessions with start and end times, which it sums into hours. Everything past that point is interpretation, not new data.
Git-based time tracking measures *when outputs landed*, then infers the effort that produced them. You will often see "when you committed" and "how long you worked" treated as the same number, and that conflation is where inflated estimates come from.
How it differs from the other tracking categories
There are really three ways developers track coding time, and they trade setup against accuracy. Before the table, the honest summary: git-based is the lowest friction, manual is the most disruptive, and plugin-based is the most accurate per editor but the most fragmented. Here is how they line up.
| Category | Setup | What it reads | Accuracy | Best for |
|---|---|---|---|---|
| Git-based | None (reads commit history) | Commit timestamps | Low to medium on its own | A fast benchmark of when and roughly how long |
| Plugin / editor telemetry | A plugin per editor | Keystrokes, file activity | High in that editor | Heads-down work inside one IDE |
| Manual timers | Start/stop discipline | Whatever you remember to log | High if perfect, usually leaky | Billing when you log every block |
Git-based tracking wins on friction because there is nothing to install and nothing to remember. Plugin-based tools like WakaTime are accurate while you type, but you need a separate plugin for every editor and they see nothing in the terminal. Manual timers are accurate in theory and leaky in practice, because the one block you forget to start is the one the client asks about. This is why so many developers drift toward the git approach: it is the only one that keeps working when you forget it exists.
How accurate is it, really
If you have ever run a git log script and watched it confidently report "6.2 hours," you have met the core limitation. The number looks precise, but most of it is inferred from gap rules, not measured.
Git-based tracking is reliable for the *shape* of your work: which days were heavy, when a push happened, roughly how long a dense run of commits lasted. It gets shakier in three predictable places. The first commit of any session has nothing before it to measure, so the tracker has to guess a ramp-up. Long stretches of reading or debugging that end in one small commit look like almost no time at all. And a commit's size no longer tells you anything about duration. We go deeper on the methods and their error bars in time tracking from git commits.
That last point is the one 2026 broke open. An agent like Claude Code or Cursor can produce a 500-line commit in under a minute, while a one-line config fix can follow an hour of reading docs. In practice this means any method that scales time by lines changed is now actively wrong, not just rough. Commit volume and effort have come apart, and they are not going back together.
Why git data alone is a benchmark, not a clock
The reason commit-only tracking tops out at "medium" is structural, not a bug someone can patch. Git was built to version code, not to watch you work. It records the instant a commit was created and nothing about the hour that led to it.
A commit graph is a set of claims about your work, not a measurement of it. Anyone can reconstruct a plausible story from git log, which is exactly why a story told only in commits is so easy to inflate and so hard to defend when a client or a hiring manager pushes back. The fix is observing the work as it happens and using commits to cross-check, not a cleverer gap heuristic. That is the difference between a guess and a record. The pillar guide on tracking coding time from git walks through that combined approach end to end.
How to set up git-based time tracking
Most developers do not need a perfect clock; they need a number they can stand behind. If you are tracking for your own curiosity, a simple setup gets you most of the way. If you are billing from it, you need one more layer.
- Start with session grouping. Point a script or tool at your repo and group commits with a gap threshold, usually 30 minutes. Anything closer than that is one session; a bigger gap starts a new one. This gives you the baseline shape for free.
- Sanity-check against memory and calendar. The first commit of each session and any long thinking stretch are the weak spots. A quick glance at your calendar catches the obvious misses before they reach an invoice.
- Add a lightweight, editor-agnostic tracker. This is the step that counts terminal and AI-agent work instead of guessing at it, and it does not mean a plugin for every editor. One CLI can cover the gaps. See coding time tracker without an IDE plugin for why a single tracker beats a pile of per-editor plugins.
- Review the combined timeline. Commits give the benchmark, telemetry fills the gaps, and the merged view is far harder to argue with than a reconstructed log. If you bill from this, estimating developer hours from commits covers turning it into defensible hours.
Where DevClocked fits
If all you want is a rough sense of when you worked last week, you do not need a product at all. A short script over git log with a 30-minute gap rule will get you there, and for personal curiosity that is genuinely fine. The same holds if your commits are tiny and frequent, because the gap heuristic is at its best when commits are dense and the gaps it has to guess at are small.
DevClocked earns its place when the number has to be defensible or when AI does a lot of your typing. It uses your git history as the baseline, then adds telemetry from a lightweight editor extension and an editor-agnostic CLI that covers terminal and agentic coding (Claude Code, Cursor, Codex), and it learns the relationship between commits and real activity to produce calibrated time. It reports leverage, meaning output per unit of effort, not just raw hours, and it separates AI-driven work from your own, so the time you show is audited to source rather than reconstructed. If you would rather have accurate time from a per-editor plugin and do not care about the git baseline, WakaTime is the honest alternative; you can weigh the two in DevClocked vs WakaTime or browse WakaTime alternatives. Full disclosure: I build DevClocked, in public as @builtbysketch.
Common mistakes
The most common mistake is treating the session boundaries a git-based tool draws as if they were measured. They are inferred, and the first commit of every session is the weakest guess in the estimate. The second is scaling time by diff size, which the AI era has fully broken, so a big commit no longer means a long session. The third, and the most expensive, is invoicing straight from a commit-only number and assuming nobody will question it. The moment someone does, you have no underlying record to point to, which is the whole reason a tracked timeline beats a reconstructed one. If you have leaned on manual entry instead, the trade-offs are covered in git time tracking vs manual timesheets.
