How to Create a Weekly Report from Git Commits

Yes, you can generate a weekly status report directly from git commits using git log and a few bash commands. It works well for summarizing what was built, which branches saw activity, and how work was distributed across the week. For a complete report that includes meetings, code reviews, and planning time, combine git data with IDE activity tracking.

Why This Matters

Most engineering teams have some form of weekly reporting. Standup notes get forgotten by Wednesday. Status update emails take 20 minutes to write and nobody reads them carefully. End-of-week reports are reconstructed from memory, which means they are incomplete and biased toward whatever happened most recently.

Meanwhile, your git history contains a precise, timestamped record of every piece of work that produced code. Commit messages describe what was done. Branch names indicate which feature or bug fix the work belonged to. The timestamps show when work happened and how it was distributed across the week. This is exactly the raw material a weekly report needs.

The problem is that raw git log output is not a report. It is a reverse-chronological list of individual changes that needs to be grouped, summarized, and formatted before it is useful to a manager, client, or stakeholder. The scripts below handle that transformation.

Short Answer

Run git log --since="last monday" --author="Your Name" to pull the week's commits. Group them by day or branch using awk. Format the output as a markdown summary with sections for each day or project. For teams that need reports automatically, use an IDE plugin like CodeClocker that generates weekly summaries from continuous activity data and commit history without any manual scripting.

Step-by-Step

1. Pull Your Commits for the Week

Start with a filtered git log that shows only your commits from the current week, grouped by date.

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

The --reverse flag puts commits in chronological order, which reads more naturally in a report. Output looks like this:

2026-04-20 09:12 | Set up database migration for user preferences table
2026-04-20 11:45 | Add API endpoints for preference CRUD operations
2026-04-20 15:30 | Write integration tests for preference endpoints
2026-04-21 10:08 | Fix timezone handling in preference sync logic
2026-04-21 14:22 | Implement frontend settings panel component
2026-04-21 16:50 | Connect settings panel to preference API
2026-04-22 09:30 | Add validation for preference value constraints
2026-04-22 11:15 | Handle edge case for users migrating from legacy settings
2026-04-22 14:45 | Update API documentation for v2 preference endpoints
2026-04-23 10:00 | Code review fixes from PR #247 feedback
2026-04-23 13:30 | Add preference export/import functionality
2026-04-23 16:15 | Final QA pass and merge to staging

2. Group Commits by Day with a Bash Script

A flat list of commits is useful but hard to scan. This script groups commits by day and adds a commit count per day.

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

git log --author="$AUTHOR" --since="$SINCE" \
  --format="%ad|%s" --date=format:"%Y-%m-%d %H:%M" --reverse | \
awk -F'|' '{
  split($1, dt, " ");
  day = dt[1];
  if (day != prev_day) {
    if (prev_day != "") printf "\n";
    printf "## %s\n", day;
    count[day] = 0;
    prev_day = day;
  }
  count[day]++;
  printf "- %s\n", $2;
}'

Output:

## 2026-04-20
- Set up database migration for user preferences table
- Add API endpoints for preference CRUD operations
- Write integration tests for preference endpoints

## 2026-04-21
- Fix timezone handling in preference sync logic
- Implement frontend settings panel component
- Connect settings panel to preference API

## 2026-04-22
- Add validation for preference value constraints
- Handle edge case for users migrating from legacy settings
- Update API documentation for v2 preference endpoints

## 2026-04-23
- Code review fixes from PR #247 feedback
- Add preference export/import functionality
- Final QA pass and merge to staging

3. Summarize by Branch or Project

If you work across multiple branches or repositories, grouping by branch tells a clearer story than grouping by day.

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

# Group commits by branch (using decorate to show branch refs)
for repo in ~/projects/*/; do
  if [ -d "$repo/.git" ]; then
    project=$(basename "$repo")
    commits=$(git -C "$repo" log --author="$AUTHOR" --since="$SINCE" \
      --format="- %s" --reverse 2>/dev/null)
    if [ -n "$commits" ]; then
      count=$(echo "$commits" | wc -l | tr -d ' ')
      echo "## $project ($count commits)"
      echo "$commits"
      echo ""
    fi
  fi
done

Output for a developer working across three repos:

## billing-service (5 commits)
- Add retry logic for failed invoice generation
- Fix race condition in concurrent payment processing
- Update Stripe SDK to v12.3
- Add webhook signature verification
- Write load test for payment endpoint

## user-dashboard (4 commits)
- Implement settings panel component
- Connect preference API to frontend
- Add preference export functionality
- Fix responsive layout on mobile settings page

## infra-config (2 commits)
- Update staging environment variables for preference service
- Add monitoring alert for preference sync failures

4. Format as a Complete Weekly Report

Combine the above into a formatted report with a summary section. This script produces markdown output you can paste into Slack, email, or a project management tool.

#!/bin/bash
AUTHOR="Your Name"
SINCE="last monday"
WEEK=$(date -d "last monday" +"%B %d" 2>/dev/null || date -v-monday +"%B %d")
WEEK_END=$(date +"%B %d, %Y")

echo "# Weekly Report: $WEEK - $WEEK_END"
echo ""
echo "**Author:** $AUTHOR"
echo ""

# Summary stats
total=$(git log --author="$AUTHOR" --since="$SINCE" --oneline | wc -l | tr -d ' ')
days=$(git log --author="$AUTHOR" --since="$SINCE" \
  --format="%ad" --date=format:"%Y-%m-%d" | sort -u | wc -l | tr -d ' ')
echo "**Total commits:** $total across $days active days"
echo ""

# Daily breakdown
echo "## Daily Breakdown"
echo ""
git log --author="$AUTHOR" --since="$SINCE" \
  --format="%ad|%s" --date=format:"%Y-%m-%d" --reverse | \
awk -F'|' '{
  day = $1;
  if (day != prev_day) {
    if (prev_day != "") printf "\n";
    printf "### %s\n", day;
    prev_day = day;
  }
  printf "- %s\n", $2;
}'

5. Layer on IDE Activity Data for Full Coverage

Git commits only capture moments when code was saved. They miss the hours spent reading code, debugging without a fix, reviewing pull requests, attending architecture discussions, and responding to questions on Slack. For senior developers, this non-commit work can represent 30 to 50 percent of the week.

An IDE plugin like CodeClocker fills these gaps by recording continuous coding sessions, tracking which files and projects were active, and linking sessions to the branches and commits produced during that time. At the end of the week, it generates a report that includes both the commit-backed deliverables and the active coding time that produced them. The developer reviews the draft, adds notes for anything that happened outside the IDE, and the report is ready to share.

Example

Here is a complete weekly report generated from git data for a developer working on a billing service.

Input: Running the daily-grouped script against the billing-service repo for the week of April 20.

Output:

# Weekly Report: April 20 - April 24, 2026

**Author:** Sarah Chen
**Total commits:** 11 across 4 active days

## Daily Breakdown

### 2026-04-20 (Monday)
- Set up database migration for invoice templates table
- Add API endpoints for template CRUD operations
- Write integration tests for template validation

### 2026-04-21 (Tuesday)
- Fix timezone handling in scheduled invoice generation
- Implement retry logic for failed Stripe API calls
- Add circuit breaker for payment gateway timeouts

### 2026-04-22 (Wednesday)
- Handle edge case for prorated invoices on plan changes
- Update API documentation for v2 invoice endpoints

### 2026-04-23 (Thursday)
- Code review fixes from PR #312 feedback
- Add invoice PDF export with custom branding
- Final QA pass and merge to staging

What the report captured well: A clear narrative of the week's progress. Monday was setup and scaffolding. Tuesday was core logic and error handling. Wednesday was edge cases and documentation. Thursday was polish and delivery. A manager reading this understands what was built and that the feature moved from foundation to staging in four days.

What the report missed: Wednesday shows only two commits because Sarah spent the morning in a design review for the next sprint's authentication overhaul and the afternoon pairing with a junior developer on their first payment integration PR. Thursday's "code review fixes" commit took 30 minutes, but the preceding code review conversation on the PR took two hours. None of this appears in git. An IDE-based tracker would have recorded the active coding hours, flagging Wednesday as a 3-hour coding day so Sarah could annotate the remaining 5 hours with meeting and review notes.

Common Mistakes

1. Not grouping commits into a narrative. A list of 40 commits sorted by timestamp is not a report. Managers and clients want to understand what was accomplished, not read every individual change. Group by feature, project, or day, and summarize clusters of related commits into one-line descriptions when the report is for a non-technical audience.

2. Missing non-commit work entirely. Code reviews, architecture discussions, debugging sessions that end with a config change, pair programming where only one person commits, mentoring, and incident response are all real work that produces zero git activity. A git-only report will systematically undercount senior developers who spend significant time on these activities.

3. Counting merge commits as work. Merge commits and automated CI commits inflate the report without representing actual developer effort. Filter them out with --no-merges in your git log command. Otherwise your commit counts will be misleading.

4. Ignoring multi-repo workflows. Developers who touch multiple repositories in a week need a report that aggregates across all of them. Running git log against a single repo produces a partial picture. Use the multi-repo script from Step 3 or a tool that tracks activity across projects automatically.

5. Forgetting that rebases rewrite history. If your team uses interactive rebase or squash merges, the commit history on the main branch will not match what the developer actually did during the week. Generate reports from feature branches before they are merged, or use a tool that captures activity in real-time rather than reconstructing it from post-merge history.

FAQ

Can I automate this to run every Friday?
Yes. Add the report script to a cron job (0 17 * * 5 for every Friday at 5 PM) and pipe the output to a file or send it via email with mail or a Slack webhook. For teams, a tool like CodeClocker generates weekly reports automatically without any cron setup.

Does this work with monorepos?
Yes, but you will want to filter by directory path to separate work by project. Use git log -- path/to/service to scope commits to a specific subdirectory. This gives you per-service breakdowns within a single repository.

How do I include code review time?
Git does not track time spent reviewing other people's code. You can pull your PR review activity from GitHub or GitLab APIs (gh pr list --reviewed-by @me), but this only tells you which PRs you reviewed, not how long the reviews took. For accurate review time tracking, you need a tool that monitors your activity across the browser and IDE.

What if developers have inconsistent commit messages?
Poorly written commit messages produce poorly written reports. If your team's commits say things like "fix," "WIP," or "stuff," the generated report will be useless. Enforce commit message standards with a git hook or use conventional commits. Alternatively, use IDE tracking that captures project and file context independently of commit message quality.

Can I generate reports for the whole team?
Remove the --author filter and add --format="%an|%ad|%s" to include author names. Then group by author in the awk script. For teams larger than five, this gets unwieldy fast and you are better off using a dedicated reporting tool.

Final Recommendation

Start by running the day-grouped script this Friday against your main repository. Compare the output to what you would have written manually. If you commit frequently with descriptive messages, the generated report will cover 70 to 80 percent of your actual work with zero effort.

For the remaining 20 to 30 percent, you have two options. The low-tech approach is to keep a running note during the week of non-coding activities and append them to the generated report on Friday. The automated approach is to use an IDE plugin that tracks your full working session, links it to commits and branches, and produces a weekly report that includes both the code output and the time invested. Either way, you should never have to reconstruct a week of work from memory again.