How to Generate a Timesheet from Git Commits

Your git log already contains a detailed record of everything you built this week. Every commit has a timestamp, an author, a branch name, and a message describing the work. If you could extract that data and format it into a timesheet, you would never have to manually reconstruct your hours again. This is not a theoretical idea. Thousands of developers use git commit history as the foundation for their timesheets, whether through simple shell commands, custom scripts, or dedicated tools. This guide walks through each approach, from raw git log commands to fully automated solutions, so you can pick the one that fits your team.

Why Teams Want Timesheets from Git Commits

The appeal of generating a timesheet from git commits is straightforward: the data already exists. Every developer on your team is already committing code multiple times a day. Those commits carry timestamps, branch names, and authorship information. Turning that existing data into a time report feels like free accounting.

There are several concrete reasons teams pursue this approach. Client billing is the most common driver. Agencies and consultancies that bill on a time-and-materials basis need to produce weekly or monthly time reports for each client project. If you can derive those reports directly from git history, you get both a timesheet and a proof of work report in one step. The client can see not just "40 hours billed" but exactly which commits and branches those hours produced.

Compliance and audit requirements push teams in the same direction. Government contractors subject to DCAA audits, financial services firms with SOX obligations, and healthcare organizations with HIPAA requirements all need defensible time records. Git commit history provides an immutable, timestamped trail of work that is much harder to fabricate than a manually entered spreadsheet. When an auditor asks "what was this developer doing on March 14th," you can point to specific commits rather than a self-reported entry that says "development work, 8 hours."

Internal accountability and project estimation round out the picture. Engineering managers who want to understand how time is distributed across projects can analyze commit patterns to see where hours are actually going versus where they were planned to go. Over time, this data becomes the foundation for better sprint planning and more accurate project estimates.

The underlying motivation is always the same: developers already produce a rich data trail through their normal workflow. Why make them manually duplicate that information in a separate timesheet system?

The DIY Approach: Git Log Commands for Time Extraction

Let us start with the hands-on approach. Git provides everything you need to extract time data from the command line. Here are the most useful commands for building a git-based timesheet.

List All Commits by a Specific Author This Week

The most basic starting point is pulling your own commits for the current week.

git log --author="Your Name" --since="last monday" --until="now" \
  --format="%ad | %s" --date=format:"%Y-%m-%d %H:%M"

This outputs a clean list of commit timestamps and messages. The output looks something like this:

2026-04-20 14:32 | Fix payment validation edge case for expired cards
2026-04-20 11:15 | Add unit tests for payment processor retry logic
2026-04-19 16:48 | Refactor payment gateway interface to support multi-provider
2026-04-19 10:22 | Update API schema for v2 billing endpoints
2026-04-18 15:30 | Implement webhook handler for Stripe subscription events
2026-04-18 09:45 | Set up integration test fixtures for billing module

From this output, you can see which days you were active and roughly when your work sessions started and ended. Monday had commits from 9:45 AM to 3:30 PM. Tuesday from 10:22 AM to 4:48 PM. Wednesday from 11:15 AM to 2:32 PM.

Group Commits by Date for a Daily Breakdown

To get a per-day summary that looks more like a traditional timesheet, you can group by date.

git log --author="Your Name" --since="2026-04-14" --until="2026-04-21" \
  --format="%ad" --date=format:"%Y-%m-%d" | sort | uniq -c

This gives you a commit count per day:

   3 2026-04-14
   5 2026-04-15
   2 2026-04-16
   4 2026-04-17
   6 2026-04-18

Commit count alone does not tell you hours, but it gives you a quick sanity check on which days you were actively coding.

Estimate Hours from First and Last Commit Per Day

A common heuristic for estimating daily hours is to measure the span between the first and last commit of each day. Here is a bash script that does this across all repos in a directory.

#!/bin/bash
AUTHOR="Your Name"
SINCE="2026-04-14"
UNTIL="2026-04-21"

git log --author="$AUTHOR" --since="$SINCE" --until="$UNTIL" \
  --format="%ad" --date=format:"%Y-%m-%d %H:%M" | \
sort | \
awk -F'|' '{
  split($1, dt, " ");
  day = dt[1];
  time = dt[2];
  if (!(day in first)) { first[day] = time; }
  last[day] = time;
}
END {
  for (day in first) {
    split(first[day], s, ":");
    split(last[day], e, ":");
    start_min = s[1]*60 + s[2];
    end_min = e[1]*60 + e[2];
    hours = (end_min - start_min) / 60;
    printf "%s: %.1f hours (first commit: %s, last commit: %s)\n",
      day, hours, first[day], last[day];
  }
}' | sort

The output looks like a rough daily timesheet:

2026-04-14: 5.8 hours (first commit: 09:45, last commit: 15:30)
2026-04-15: 6.4 hours (first commit: 10:22, last commit: 16:48)
2026-04-16: 3.3 hours (first commit: 11:15, last commit: 14:32)
2026-04-17: 7.0 hours (first commit: 09:15, last commit: 16:15)
2026-04-18: 6.2 hours (first commit: 10:00, last commit: 16:12)

Break Down Time by Branch or Project

If you work across multiple projects or branches, you can group the output by branch to produce a per-project breakdown.

git log --author="Your Name" --since="last monday" --all \
  --format="%ad|%D|%s" --date=format:"%Y-%m-%d %H:%M" | \
grep -v "^$" | head -20

For multi-repo setups, you can wrap this in a loop that iterates over each project directory:

#!/bin/bash
AUTHOR="Your Name"
SINCE="last monday"

for repo in ~/projects/*/; do
  if [ -d "$repo/.git" ]; then
    project=$(basename "$repo")
    count=$(git -C "$repo" log --author="$AUTHOR" --since="$SINCE" \
      --oneline 2>/dev/null | wc -l | tr -d ' ')
    if [ "$count" -gt 0 ]; then
      echo "--- $project ($count commits) ---"
      git -C "$repo" log --author="$AUTHOR" --since="$SINCE" \
        --format="  %ad | %s" --date=format:"%Y-%m-%d %H:%M"
      echo ""
    fi
  fi
done

This gives you a per-project commit log that you can use as the basis for a timesheet broken down by client or project.

The Limitations of Pure Git-Based Timesheets

The commands above are useful, and for a solo developer billing a single client, they might be all you need. But once you start relying on git commit history as your primary timesheet source, the limitations become apparent quickly. Understanding these gaps is important before you build a process around this approach.

Commits Are Points, Not Spans

The most fundamental problem is that a git commit records the moment code was saved, not the duration of the work that produced it. If a developer makes a commit at 10:00 AM and the next commit at 2:00 PM, you do not know whether they were coding for four straight hours, or whether they took a 90-minute lunch break in the middle. The first-commit-to-last-commit heuristic gives you a span, but that span includes every break, meeting, context switch, and interruption that happened between those bookends.

This matters most for billing. If you tell a client that a developer worked 7 hours on their project because their first commit was at 9 AM and their last was at 4 PM, you might be overstating the actual coding time by 2 or 3 hours. On the flip side, a developer who makes their last commit at 3 PM but then spends another hour reviewing pull requests and answering questions about their code has that hour invisible in the git log.

Commit Frequency Varies Wildly Between Developers

Some developers commit every 15 to 30 minutes. Others work for hours before making a single large commit with all their changes. A developer who commits frequently produces a git log that maps closely to their actual work timeline. A developer who makes three commits per day produces a log with massive gaps that tell you almost nothing about what happened between those points.

You might think you can standardize commit frequency across the team, but in practice, commit patterns are deeply ingrained habits that developers resist changing. Forcing frequent commits for the sake of time tracking produces noise commits that pollute the git history and frustrate the very developers you are trying to track.

Non-Coding Work Is Invisible

A significant portion of a developer's week does not produce commits. Code reviews, design discussions, debugging sessions that end with a one-line fix, pair programming sessions where only one person commits, reading documentation, responding to technical questions in Slack, attending architecture meetings, and onboarding new team members are all real, billable work that produces zero git activity. For many senior developers, this non-commit work can account for 30 to 40 percent of their week. A timesheet derived purely from git history misses all of it.

Multiple Repos and Branch Switching Create Noise

Real-world development rarely involves a single repository. A developer working across a backend service, a frontend application, a shared library, and an infrastructure repo might make commits in four different git histories in a single day. Aggregating these into a single timesheet requires scanning all repos, deduplicating time windows where work overlapped, and handling timezone differences if repos are hosted in different environments. The bash scripts get complicated fast, and edge cases multiply with every additional repo.

Merge Commits and Rebasing Distort Timestamps

When developers rebase branches or squash commits before merging, the original commit timestamps can be overwritten. A commit that was actually created on Monday might show a Wednesday timestamp after a rebase. Interactive rebasing, force pushes, and cherry-picks all create situations where the git log no longer accurately reflects when work was performed. If your timesheet depends on commit timestamps being accurate, your process is one rebase away from producing incorrect data.

The 80/20 Problem

Git-based timesheets can capture roughly 60 to 70 percent of a typical developer's work, which is better than nothing but not good enough for client invoicing or compliance reporting. The remaining 30 to 40 percent either gets lost entirely or requires manual supplementation, which brings you right back to the problems of manual timesheet entry for a significant chunk of the work week. This is the core tension: git commit data is a great starting point, but it is not a complete solution.

From Git Commits to IDE Activity: A Better Data Source

The insight behind IDE-based time tracking is simple: if you want to know how long a developer worked, instrument the tool where the work actually happens. An IDE plugin can detect the start and end of every coding session with much higher fidelity than commit timestamps alone.

When a developer opens a project in IntelliJ, PyCharm, or any JetBrains IDE, the plugin starts tracking. It records when files are being actively edited, when the developer switches between projects, and when the IDE goes idle because the developer stepped away. This produces a continuous timeline of coding activity rather than a series of disconnected points.

Consider the difference. A git-based approach sees: commit at 9:15 AM, commit at 11:45 AM, commit at 2:30 PM. From this, you can estimate that work happened sometime between 9:15 AM and 2:30 PM, but you have no idea what the actual pattern was. An IDE-based approach sees: active coding from 9:02 AM to 10:48 AM (1 hour 46 minutes), idle from 10:48 to 11:15 (break or meeting), active coding from 11:15 AM to 12:30 PM (1 hour 15 minutes), idle from 12:30 to 1:30 (lunch), active coding from 1:30 PM to 2:35 PM (1 hour 5 minutes). Total tracked coding time: 4 hours 6 minutes. The git-based estimate from commit spans would have reported something closer to 5 hours 15 minutes, overstating actual coding time by more than an hour.

Critically, IDE-based tracking does not replace git data. It enhances it. The best approach links IDE activity sessions to the git commits and branches that were active during those sessions. You get both the duration data (how long the developer was actively coding) and the evidence data (what they produced during that time). This is what turns raw hours into something you can attach to a client invoice as a defensible proof of work report.

How CodeClocker Combines Commits and IDE Activity

CodeClocker takes the hybrid approach described above. It is a JetBrains IDE plugin that passively captures coding sessions and associates them with git context, then generates weekly timesheets that developers review and managers approve.

Here is how the data flows in practice. A developer installs the plugin in their IDE. From that point on, the plugin silently records coding sessions: which project is open, which branch is checked out, how long the developer is actively editing files. When the developer makes a commit, that commit is linked to the active coding session. At the end of the week, CodeClocker uses this combined data to auto-generate a timesheet that breaks down hours by project and by day, with commit references attached as evidence.

The developer opens their weekly timesheet and sees something like this: Monday, 6.2 hours on Project Alpha (feature/payment-retry branch, 4 commits). Tuesday, 3.5 hours on Project Alpha, 2.8 hours on Project Beta (fix/auth-timeout branch, 2 commits). The numbers come from actual IDE activity, not from first-to-last commit spans or manual recall. The developer reviews the draft, adds a note if something was missed (a 45-minute architecture meeting that happened outside the IDE, for example), and submits. Their manager reviews and approves with a single click.

This addresses every limitation of the pure git approach. Coding sessions are measured as continuous activity, not point-in-time snapshots. Idle time and breaks are excluded automatically. Multi-project and multi-repo work is captured through IDE project detection. And the commit linkage provides the evidence trail that makes the timesheet defensible for billing and compliance. For teams dealing with billable hours leakage, this combination of accurate time capture and commit evidence can recover revenue that was previously lost to underreporting.

Choosing the Right Approach for Your Team

The right approach depends on your team size, your accuracy requirements, and how the timesheet data will be used downstream. Here is a practical framework for deciding.

Solo freelancer billing a single client: The git log commands shown earlier in this article may be all you need. If you commit frequently and your work is almost entirely coding, the first-to-last commit heuristic gives you a reasonable daily estimate. Supplement with a simple note for non-coding hours (meetings, research, client calls) and you have a workable system with zero tooling cost.

Small team (2 to 5 developers) with basic billing needs: A bash script that aggregates git logs across your repos and generates a weekly summary per developer is a solid intermediate step. You will need to standardize on commit message conventions and decide how to handle gaps and non-coding work. This approach scales poorly beyond a handful of developers, but for a small team it can work for months before the maintenance burden becomes significant.

Teams of 5 or more with client billing or compliance requirements: At this scale, the limitations of git-only approaches start to cause real problems. Different commit frequencies across developers mean some timesheets are accurate and others are not. Non-coding work gaps become a significant source of underreported developer hours. Manager review and approval needs a structured workflow rather than emailed spreadsheets. This is where IDE-based tracking with commit linkage pays for itself through better accuracy, less manual effort, and audit-ready exports.

Agencies and consultancies billing multiple clients: If your developers split their time across multiple client projects in a single week, accurate per-project breakdown is essential for correct invoicing. Git-based approaches struggle here because developers frequently switch between repos and branches throughout the day, and allocating time to the correct project from commit timestamps alone is unreliable. IDE-based tracking captures project switches in real-time, producing per-project breakdowns that match actual work patterns rather than commit-based estimates.

Getting Started: A Practical Workflow

Regardless of which approach you choose, here is a workflow you can implement this week to start generating timesheets from your git activity.

Step 1: Audit your current commit patterns. Before building anything, run the git log commands above against your last two weeks of history. Look at how many commits per day each developer makes, how much time elapses between commits, and whether commit timestamps cluster around actual work hours. This tells you how reliable git-based time estimation will be for your specific team.

Step 2: Set up a weekly reporting cadence. Pick a day and time each week when timesheets are due. Friday at 4 PM is the most common choice. Whether you are using shell scripts or an automated tool, the cadence creates accountability and ensures time data is captured while the week is still fresh.

Step 3: Choose your level of automation. If you are starting simple, save the bash script from earlier in this article and run it every Friday. If you need more accuracy and less manual work, install an IDE plugin that captures sessions automatically. The key is to start somewhere and iterate. A git-based timesheet that is 70 percent accurate and takes 5 minutes to review is vastly better than a manual timesheet that is 60 percent accurate and takes 30 minutes to construct from memory.

Step 4: Build in a review step. Whatever data source you use, have the developer review the generated timesheet before it goes to a manager or a client. This catch-all step handles the edge cases that no automated system can detect: meetings that happened outside the IDE, pair programming sessions where one developer drove, travel time for on-site client work, or half-days taken for personal reasons. The review should be fast, 2 to 5 minutes, because the heavy lifting is already done by the data.

Step 5: Export in the format your downstream consumers need. Finance typically wants CSV files they can import into accounting software. Client-facing teams want PDF summaries attached to invoices. Compliance teams want detailed logs with timestamps and evidence. Make sure your process produces output in the right format so that nobody has to manually reformat data after the timesheet is approved.

The Bottom Line

Git commit history is an underused data source for timesheet generation. The timestamps, branch names, and author information already sitting in your repositories contain most of the raw material you need to produce weekly time reports. For solo developers and small teams, a few git log commands and a bash script can replace manual time entry entirely. For larger teams with billing accuracy requirements, the same git data becomes even more powerful when combined with IDE-based session tracking that fills in the gaps between commits.

The practical takeaway is this: start with what you have. Run the git log commands from this article against your last week's commits and see how closely the output matches your actual work patterns. If the fit is close enough, script it and make it your Friday routine. If you need higher accuracy, tighter per-project breakdowns, or team-wide approval workflows, layer on IDE tracking that captures the full picture while still linking every hour to its underlying commits and branches. Either way, you are building timesheets from real work data instead of guessing from memory, and that is a better foundation for billing, compliance, and project planning than any manual process can provide.