Generate a Developer Weekly Report from Git Commits

You can generate a developer-focused weekly report from git commits by combining git log with scripts that group work by project, estimate active hours, and format the output for different audiences. The result covers what you built, where your time went, and which deliverables shipped, all pulled from data that already exists in your repositories.

Why This Matters

Developers are asked to report on their work constantly. Sprint retrospectives want to know what was completed. Managers need capacity data for planning. Clients expect progress updates tied to billable hours. Contract teams face audit requirements that demand evidence of who did what and when.

But developers are not project managers. Writing status reports means context-switching from code to prose, reconstructing a week of work from fragments of memory, and translating technical changes into language that non-technical stakeholders understand. Most developers either underreport (forgetting the debugging session that consumed Tuesday afternoon) or pad with vague descriptions ("worked on backend improvements") because the real details have faded by Friday.

Your git history does not forget. Every commit carries a timestamp, an author, a branch name, and a message describing the change. Across a typical week, a developer produces 20 to 50 commits that form a precise audit trail of their output. The challenge is transforming that raw data into a report that serves different audiences: a technical lead wants commit-level detail, a product manager wants feature-level summaries, and a client wants hours mapped to deliverables.

Short Answer

Use git log with author and date filters to pull your week's commits. Run a script that groups them by project and branch, calculates the time span per day, and formats the output as markdown. For reports that also include hours spent on code reviews, debugging, and meetings, use an IDE plugin like CodeClocker that tracks your full development session and generates weekly reports automatically.

Step-by-Step

1. Extract Your Weekly Activity from Git

Start with a comprehensive pull of your commits across the week, including branch context.

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

The %D format specifier includes ref names (branch tags), which helps map commits to features. Output:

2026-04-20 09:15 |  | Add database schema for notification preferences
2026-04-20 11:30 |  | Implement notification dispatch service
2026-04-20 14:45 |  | Write unit tests for dispatch retry logic
2026-04-20 16:20 | HEAD -> feature/notifications | Add rate limiting to notification API
2026-04-21 09:40 |  | Fix N+1 query in user subscription lookup
2026-04-21 11:15 |  | Optimize batch notification delivery pipeline
2026-04-21 15:30 | HEAD -> feature/notifications | Add dead letter queue for failed deliveries
2026-04-22 10:00 |  | Refactor authentication middleware for token refresh
2026-04-22 13:45 |  | Add integration tests for OAuth2 token rotation
2026-04-22 16:00 | HEAD -> fix/auth-token-refresh | Fix edge case in concurrent token refresh
2026-04-23 09:30 |  | Update CI pipeline to run notification integration tests
2026-04-23 11:00 |  | Add Grafana dashboard config for notification metrics
2026-04-23 14:30 | HEAD -> feature/notifications | Merge notification feature to staging

2. Group by Feature Branch for Narrative Reports

Managers and product owners think in features, not commits. This script groups your work by branch so the report reads as a progress update per deliverable.

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

echo "# Developer Weekly Report"
echo "**Developer:** $AUTHOR"
echo "**Week of:** $(date -d 'last monday' '+%B %d, %Y' 2>/dev/null || date -v-monday '+%B %d, %Y')"
echo ""

# Get all branches with commits this week
git log --author="$AUTHOR" --since="$SINCE" --all \
  --format="%D" | tr ',' '\n' | sed 's/^ //' | \
  grep -v '^$' | grep -v 'HEAD' | grep -v 'origin/' | \
  sort -u | while read branch; do
    commits=$(git log --author="$AUTHOR" --since="$SINCE" \
      "$branch" --format="- %s" --reverse 2>/dev/null)
    if [ -n "$commits" ]; then
      count=$(echo "$commits" | wc -l | tr -d ' ')
      # Get date range
      first=$(git log --author="$AUTHOR" --since="$SINCE" \
        "$branch" --format="%ad" --date=format:"%a %b %d" \
        --reverse 2>/dev/null | head -1)
      last=$(git log --author="$AUTHOR" --since="$SINCE" \
        "$branch" --format="%ad" --date=format:"%a %b %d" \
        2>/dev/null | head -1)
      echo "## $branch"
      echo "*$count commits | $first - $last*"
      echo ""
      echo "$commits"
      echo ""
    fi
done

Output:

# Developer Weekly Report
**Developer:** Sarah Chen
**Week of:** April 20, 2026

## feature/notifications
*10 commits | Mon Apr 20 - Wed Apr 23*

- Add database schema for notification preferences
- Implement notification dispatch service
- Write unit tests for dispatch retry logic
- Add rate limiting to notification API
- Fix N+1 query in user subscription lookup
- Optimize batch notification delivery pipeline
- Add dead letter queue for failed deliveries
- Update CI pipeline to run notification integration tests
- Add Grafana dashboard config for notification metrics
- Merge notification feature to staging

## fix/auth-token-refresh
*3 commits | Tue Apr 22 - Tue Apr 22*

- Refactor authentication middleware for token refresh
- Add integration tests for OAuth2 token rotation
- Fix edge case in concurrent token refresh

3. Add Time Estimates per Feature

For teams that need hours mapped to deliverables, especially agencies billing clients or contractors tracking against budgets, add a time estimation layer.

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

echo "# Weekly Activity Report with Time Estimates"
echo ""

# Per-day time spans
git log --author="$AUTHOR" --since="$SINCE" \
  --format="%ad" --date=format:"%Y-%m-%d %H:%M" | sort | \
awk '{
  split($1, d, "-"); split($2, t, ":");
  day = $1;
  mins = t[1]*60 + t[2];
  if (!(day in first_min)) { first_min[day] = mins; first_t[day] = $2; }
  last_min[day] = mins; last_t[day] = $2;
  count[day]++;
}
END {
  total = 0;
  printf "| Day | First Commit | Last Commit | Span | Commits |\n";
  printf "|-----|-------------|-------------|------|---------|\n";
  n = asorti(first_min, sorted);
  for (i = 1; i <= n; i++) {
    day = sorted[i];
    hours = (last_min[day] - first_min[day]) / 60;
    total += hours;
    printf "| %s | %s | %s | %.1fh | %d |\n",
      day, first_t[day], last_t[day], hours, count[day];
  }
  printf "\n**Total estimated span:** %.1f hours\n", total;
  printf "**Adjusted estimate (minus breaks):** %.1f hours\n", total * 0.8;
}'

Output:

| Day | First Commit | Last Commit | Span | Commits |
|-----|-------------|-------------|------|---------|
| 2026-04-20 | 09:15 | 16:20 | 7.1h | 4 |
| 2026-04-21 | 09:40 | 15:30 | 5.8h | 3 |
| 2026-04-22 | 10:00 | 16:00 | 6.0h | 3 |
| 2026-04-23 | 09:30 | 14:30 | 5.0h | 3 |

**Total estimated span:** 23.9 hours
**Adjusted estimate (minus breaks):** 19.2 hours

The 0.8 multiplier is a rough adjustment for lunch and breaks. It is a starting point, not an accurate measurement. For precise hours, you need a tool that tracks active time rather than inferring it from commit timestamps.

4. Format for Different Audiences

The same git data can serve multiple report formats. Here are the three most common audiences and what they need.

For standup or sprint review (technical team):

# What I shipped this week
- Notification dispatch service with retry logic and rate limiting
- Dead letter queue for failed notification deliveries
- Auth token refresh fix (concurrent refresh edge case)
- CI pipeline updates and Grafana monitoring for notifications

# What's next
- Notification preference UI (frontend)
- Load testing the dispatch pipeline

For a manager or product owner (feature-level):

# Weekly Update - Sarah Chen (April 20-24)

## Notification System (feature/notifications) - SHIPPED TO STAGING
Built the backend notification service end-to-end: database schema,
dispatch engine with retry and rate limiting, dead letter queue for
reliability, and monitoring dashboards. 10 commits across 4 days.
Ready for frontend integration next week.

## Auth Bug Fix (fix/auth-token-refresh) - MERGED
Fixed a race condition where concurrent API calls could invalidate
each other's refresh tokens. Added integration test coverage to
prevent regression. 3 commits, 1 day.

For a client invoice or contract report (hours + deliverables):

# Development Report - Week of April 20, 2026
**Developer:** Sarah Chen
**Estimated hours:** 19.2 (adjusted from 23.9h commit span)

## Notification Service - 15.0 hours
- Database schema and API design (Mon)
- Core dispatch service with retry logic (Mon-Tue)
- Performance optimization and reliability (Tue-Wed)
- CI/CD and monitoring setup (Thu)

## Authentication Fix - 4.2 hours
- Root cause analysis and fix (Tue)
- Integration test coverage (Tue)

5. Automate with IDE Activity Tracking

Every script above has the same blind spot: git only records the moments code was committed, not the continuous work between commits. A developer who spends 90 minutes reading code, debugging, and testing before making a single one-line commit shows 0 minutes of activity in the git log until that commit lands.

An IDE plugin like CodeClocker solves this by recording development sessions in real-time. It tracks which files are being edited, which project is active, when the developer switches branches, and when the IDE goes idle. At the end of the week, it combines this continuous session data with the commit history to produce a report that shows both the time invested and the code produced. The developer reviews a draft, adds context for anything that happened outside the IDE, and the report is ready for whatever audience needs it.

Example

Here is a side-by-side comparison of what a git-only report captures versus what actually happened during a developer's week.

Git-only report for Marcus (backend developer):

Monday:    4 commits, 09:00 - 16:30 (7.5h span)
Tuesday:   2 commits, 10:15 - 14:30 (4.3h span)
Wednesday: 5 commits, 09:30 - 17:00 (7.5h span)
Thursday:  1 commit,  11:00 - 11:00 (0.0h span)
Friday:    3 commits, 09:15 - 15:45 (6.5h span)

Total span: 25.8 hours
Adjusted (x0.8): 20.6 hours

What actually happened:

Monday was accurate. Marcus worked on the payment integration all day. The commits reflect steady progress.

Tuesday shows only 4.3 hours because Marcus spent the morning in a 2-hour architecture review for the upcoming microservices migration, then wrote code in the afternoon. The architecture review was billable project work, but it produced zero commits.

Wednesday is inflated. The 7.5-hour span included a 90-minute lunch and a 45-minute coffee break with a recruiter. Actual coding time was closer to 5.25 hours.

Thursday shows one commit at 11 AM, which the script counted as zero hours. In reality, Marcus spent the entire day pairing with a junior developer on their first production deployment. Marcus drove for most of the session, but they committed from the junior developer's machine. Marcus's actual contribution was 7 hours.

Friday was close to accurate, though Marcus also spent 45 minutes reviewing two pull requests that produced no commits on his end.

Corrected totals: Git reported 20.6 adjusted hours. Actual billable work was closer to 31 hours. The 10-hour gap was architecture review, pair programming, and code reviews, all legitimate developer work invisible to git.

Common Mistakes

1. Sending raw git log output as your report. A list of 35 commits with messages like "fix test," "update migration," and "address PR feedback" communicates nothing to a non-developer audience. Always group, summarize, and contextualize. A report should tell the story of the week, not dump a database.

2. Reporting commit count as a productivity metric. Some developers commit every ten lines. Others batch work into large, well-structured commits. A developer with 50 commits did not necessarily accomplish more than one with 8. Use commits as evidence of what was built, not how productive someone was.

3. Ignoring pair programming and mob sessions. When two developers pair, only one person's name appears on the commits. The other developer's entire contribution is invisible in git. If your team pairs frequently, git-based reports will systematically undercount half the participants. Use Co-authored-by trailers in commit messages or supplement with session-level tracking.

4. Not adjusting commit spans for breaks. The time between your first and last commit includes every lunch break, coffee run, and Slack conversation. Reporting 8 hours because your commits span 9 AM to 5 PM is inaccurate. Apply at minimum a 0.75 to 0.85 multiplier, or better yet, use a tool that tracks active time directly.

5. Generating reports only from the main branch. If your team uses squash merges or rebases, the main branch contains summarized versions of what happened, not the detailed commit history from feature branches. Always generate developer reports from the feature branches before they are merged, or use --all to include all branch history.

FAQ

How do I handle weeks where most of my work was non-coding?
Some weeks are dominated by design reviews, interviews, incident response, or onboarding a new team member. A git-based report will show minimal activity even though you worked a full week. For these weeks, maintain a brief running log (even a text file updated at end of day) and append it to your generated report. An IDE-based tool can at least capture the coding portions automatically, reducing what you need to track manually.

Can I generate a team-wide report from git?
Yes. Remove the --author flag and group by author using --format="%an|%ad|%s". For teams larger than five, this gets long and is better handled by a tool that aggregates and formats automatically. A team report should also highlight blocked items and cross-team dependencies, which git does not capture.

What about sensitive commit messages in client-facing reports?
Internal commit messages often contain technical jargon, profanity (yes, it happens), or references to internal systems that should not appear in a client report. Always review generated reports before sending them externally. Better yet, write a script that maps branch names to client-friendly project descriptions and only includes summarized deliverables, not raw commit messages.

Does this work with GitHub Copilot or AI-assisted coding?
AI-assisted commits are still your commits. The git log does not distinguish between code you wrote from scratch and code suggested by an AI tool. Your report should focus on what was delivered and the problems it solved, regardless of how the code was produced. The time tracking question is the same either way: how long did you spend on the task, including prompting, reviewing, and testing the AI output.

How do I include PR reviews in my report?
Use the GitHub CLI to pull your review activity: gh pr list --search "reviewed-by:@me" --state merged --json title,url. Add these to a "Code Reviews" section of your report. This shows work that consumed time and added value but produced zero commits on your branches.

Final Recommendation

If you commit at least three times a day with descriptive messages, a git-based report will cover the majority of your coding output. Add the branch-grouping script to a Friday cron job and you have an automated first draft every week.

For teams where reports need to include hours, serve as client invoices, or satisfy compliance requirements, the git-only approach hits a ceiling. The missing 20 to 40 percent of developer activity, reviews, meetings, debugging, pair programming, needs to come from somewhere. The choice is between maintaining a manual log alongside the automated git report, or using an IDE-based tracker that captures the full picture and generates the report without any manual work at all. For individual developers, the manual supplement may be sufficient. For teams of five or more, the automation pays for itself within the first week.