Generate Weekly Reports from Your Git Commits Automatically

You can generate a weekly report from your git commits automatically by combining a multi-repo collection script with a cron job that runs every Friday. The script pulls your commits, groups them by project and day, calculates activity stats, and outputs a formatted report ready for your manager, sprint review, or client. Add AI summarization for plain-language descriptions, or use an IDE plugin for reports that include actual hours worked.

Why This Matters

Writing weekly reports is one of those tasks that everyone agrees is important and nobody wants to do. Engineering managers need them for capacity planning. Clients need them for billing transparency. Compliance frameworks need them for audit trails. But the actual process of writing one, sitting down on Friday afternoon and trying to reconstruct five days of technical work, is tedious and error-prone.

The result is predictable: developers procrastinate on reports, rush them at the last minute, and produce vague summaries that undersell their work. Agencies lose billable hours because developers forget to report them. Managers make planning decisions based on incomplete data. Auditors find gaps that trigger compliance findings.

Automation changes the equation. Your git history already contains a detailed, timestamped record of your code output. A script that runs on schedule, collects this data, formats it into a report template, and delivers it to the right channel eliminates the manual work entirely. The developer's role shifts from "reconstruct the week from memory" to "review and approve a pre-built report."

Short Answer

Write a bash script that runs git log --since="last monday" --author="$(git config user.name)" across all your repos, groups the output by project and day, and saves it as a markdown file. Schedule it with cron to run every Friday at 5 PM. For reports that include hours, use an IDE plugin like CodeClocker that tracks your development sessions and generates weekly reports with actual time data.

Step-by-Step

1. Collect Commits from All Repositories

Most developers work across multiple repos in a week. This script scans a parent directory and collects commits from every git repo it finds.

#!/bin/bash
# weekly-report.sh - Collect commits and generate a weekly report

AUTHOR="$(git config user.name)"
SINCE="last monday"
WEEK_START=$(date -d "last monday" +"%B %d" 2>/dev/null || date -v-monday +"%B %d")
WEEK_END=$(date +"%B %d, %Y")

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

# Stats
total_commits=0
total_repos=0

for repo in ~/projects/*/; do
  [ -d "$repo/.git" ] || continue

  commits=$(git -C "$repo" log --author="$AUTHOR" --since="$SINCE" \
    --format="%ad|%s" --date=format:"%Y-%m-%d" --reverse 2>/dev/null)

  [ -z "$commits" ] && continue

  project=$(basename "$repo")
  count=$(echo "$commits" | wc -l | tr -d ' ')
  total_commits=$((total_commits + count))
  total_repos=$((total_repos + 1))

  echo "## $project ($count commits)"
  echo ""

  # Group by day
  echo "$commits" | awk -F'|' '{
    day = $1;
    if (day != prev) {
      if (prev != "") printf "\n";
      printf "### %s\n", day;
      prev = day;
    }
    printf "- %s\n", $2;
  }'
  echo ""
done

echo "---"
echo "**Summary:** $total_commits commits across $total_repos projects"

Output:

# Weekly Report: April 20 - April 24, 2026
**Author:** Sarah Chen

## billing-api (7 commits)

### 2026-04-20
- Add Stripe Connect onboarding flow for marketplace sellers
- Implement payout scheduling for connected accounts
- Write integration tests for Connect onboarding

### 2026-04-21
- Fix webhook signature validation for Connect events
- Add retry logic for failed payout transfers

### 2026-04-22
- Update API documentation for seller endpoints
- Add rate limiting to payout initiation endpoint

## admin-portal (5 commits)

### 2026-04-22
- Add seller onboarding status dashboard
- Implement payout history view with filtering

### 2026-04-23
- Fix date range picker timezone handling
- Add CSV export for payout reports
- Add seller verification badge to onboarding list

---
**Summary:** 12 commits across 2 projects

2. Add Time Estimates per Day

For reports that need hours, calculate the span between first and last commit each day.

#!/bin/bash
# Add this function to your weekly-report.sh

time_summary() {
  local repo="$1"
  local author="$2"
  local since="$3"

  git -C "$repo" log --author="$author" --since="$since" \
    --format="%ad" --date=format:"%Y-%m-%d %H:%M" | sort | \
  awk '{
    split($1, parts, "-");
    day = $1;
    split($2, t, ":");
    mins = t[1]*60 + t[2];
    if (!(day in first)) { first[day] = mins; ft[day] = $2; }
    last[day] = mins; lt[day] = $2;
  }
  END {
    total = 0;
    for (day in first) {
      hours = (last[day] - first[day]) / 60;
      if (hours < 0.5) hours = 0.5;
      total += hours;
      printf "  %s: %.1fh (%s - %s)\n", day, hours, ft[day], lt[day];
    }
    adjusted = total * 0.8;
    printf "\n  **Estimated:** %.1fh (adjusted: %.1fh)\n", total, adjusted;
  }'
}

This adds a time section to each project:

## billing-api (7 commits)
  2026-04-20: 6.5h (09:15 - 15:45)
  2026-04-21: 4.5h (09:30 - 14:00)
  2026-04-22: 3.0h (10:00 - 13:00)

  **Estimated:** 14.0h (adjusted: 11.2h)

The 0.8 multiplier adjusts for lunch and breaks. It is a rough heuristic, not a precise measurement. For accurate hours, use a tool that tracks active coding time directly.

3. Schedule Automatic Generation with Cron

Add the script to your crontab so it runs every Friday without manual intervention.

# Generate weekly report every Friday at 5 PM
0 17 * * 5 ~/bin/weekly-report.sh > ~/reports/$(date +\%Y-\%m-\%d).md

# Or generate and email it
0 17 * * 5 ~/bin/weekly-report.sh | mail -s "Weekly Report $(date +\%b\ \%d)" manager@company.com

Every Friday at 5 PM, the report is generated and saved to a file (or emailed). You review it Monday morning while the week is still somewhat fresh, make any corrections, and submit. Total effort: two minutes of review versus 20 minutes of manual writing.

4. Post to Slack Automatically

For teams that share reports in a Slack channel, pipe the output through a webhook.

#!/bin/bash
# weekly-report-slack.sh

WEBHOOK_URL="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"

# Generate report (reuse the collection script)
REPORT=$(~/bin/weekly-report.sh)

# Post to Slack
curl -s -X POST "$WEBHOOK_URL" \
  -H 'Content-type: application/json' \
  -d "{\"text\": \"$(echo "$REPORT" | sed 's/"/\\"/g' | sed ':a;N;$!ba;s/\n/\\n/g')\"}" \
  > /dev/null

echo "Report posted to Slack"

Schedule this in cron instead of the file-saving version, and your weekly report appears in the team channel every Friday at 5 PM. No developer needs to remember to write or post anything.

5. Add AI Summarization for Non-Technical Audiences

Raw commit messages are developer-facing. For reports going to managers, clients, or stakeholders, pipe the commit data through an LLM to produce plain-language summaries.

#!/bin/bash
# Append AI summary to the weekly report

REPORT=$(~/bin/weekly-report.sh)

SUMMARY=$(echo "$REPORT" | curl -s https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "{
    \"model\": \"claude-haiku-4-5-20251001\",
    \"max_tokens\": 1024,
    \"messages\": [{
      \"role\": \"user\",
      \"content\": \"Summarize this developer weekly report into 3-5 bullet points written for a non-technical project manager. Focus on features delivered, bugs fixed, and what shipped to staging/production. Be concise.\n\n$REPORT\"
    }]
  }" | jq -r '.content[0].text')

echo "$REPORT"
echo ""
echo "## Executive Summary"
echo "$SUMMARY"

This appends a section like:

## Executive Summary
- Marketplace seller payment integration completed and deployed to staging,
  enabling sellers to receive automated payouts through Stripe Connect
- Fixed a payment reliability issue that was causing duplicate webhook
  deliveries during network timeouts
- Admin dashboard now shows real-time seller onboarding status with
  CSV export capability for finance team reporting
- API documentation updated to support third-party integrations with
  the new seller payment endpoints

6. Use IDE Tracking for Reports with Actual Hours

Every approach above estimates hours from commit timestamp spans. The estimates are directionally correct but never precise, because commits do not capture breaks, meetings, context-switching, or deep-focus sessions that produce a single commit after hours of work.

An IDE plugin like CodeClocker generates weekly reports from a fundamentally different data source: continuous recording of your development sessions. It knows when you started coding, when you switched projects, when you went idle, and when you came back. The weekly report it produces includes:

Actual hours per project measured from active coding time, not commit spans
Commits linked to sessions so each deliverable has both the code output and the time investment
Non-commit activity like extended debugging or code review sessions that consumed time but produced no commits
Draft review workflow where the developer reviews the generated report before it is submitted

The result is a weekly report that is both automated and accurate, one that you can confidently attach to a client invoice or compliance submission.

Example

Here is the full pipeline in action for a developer named Alex.

Friday, 5:00 PM: The cron job runs. It scans three repos and collects 18 commits from the week.

Auto-generated report:

# Weekly Report: April 20 - April 24, 2026
**Author:** Alex Kim

## search-service (10 commits)

### Monday
- Implement fuzzy matching algorithm for product search
- Add search result ranking by relevance score
- Write benchmark tests for search index performance

### Tuesday
- Fix Unicode encoding in search query parser
- Optimize search index rebuild for large catalogs
- Add faceted search for category and price range

### Wednesday
- Implement search suggestions with typo tolerance
- Add A/B test framework for search ranking experiments

### Thursday
- Deploy search service to staging with feature flags
- Write load test covering 1000 concurrent search queries

## checkout-flow (5 commits)

### Wednesday
- Add express checkout for returning customers
- Implement saved payment method selection

### Thursday
- Fix race condition in cart-to-order transition
- Add order confirmation email trigger
- Write E2E tests for express checkout flow

## infra (3 commits)

### Friday
- Update Kubernetes health check configuration for search pods
- Add Prometheus metrics for search latency percentiles
- Configure auto-scaling rules for search service

---
**Summary:** 18 commits across 3 projects

## Executive Summary
- Product search overhaul completed: fuzzy matching, relevance ranking,
  faceted filters, and typo-tolerant suggestions now live on staging
- Express checkout for returning customers built end-to-end with saved
  payment methods and E2E test coverage
- Search infrastructure production-ready with health checks, latency
  monitoring, and auto-scaling configured

Monday morning: Alex reviews the report. Two corrections needed: Wednesday's "search suggestions" commit took most of the day because it required research into Levenshtein distance algorithms, which the report does not reflect. And Thursday included a 2-hour incident response for a production database issue, which produced no commits but consumed real time. Alex adds a note for each and submits.

With IDE tracking: The report would have shown "6.2h active on search-service Wednesday" (confirming the long suggestion implementation) and "2.1h unlinked session Thursday" (flagging the incident response time for annotation). The corrections Alex made manually would have been prompted automatically.

Common Mistakes

1. Generating reports only from the main branch. If your team uses feature branches with squash merges, the detailed commit history exists only on the feature branch. After merging, it collapses into a single merge commit. Generate reports from --all branches or run the script before merges happen.

2. Not adjusting for the 80 percent rule. Commit timestamp spans include every break, meeting, and interruption. Reporting 8 hours because your commits span 9 AM to 5 PM is a guarantee of inaccuracy. Apply at minimum a 0.75 to 0.85 multiplier, and flag any day where the adjusted estimate still seems high.

3. Sending the same report format to every audience. Your tech lead wants commit-level detail. Your manager wants feature-level summaries. Your client wants hours mapped to deliverables. A single report format serves none of them well. Generate the detailed version and use AI to produce audience-specific summaries.

4. Running the script against stale local repos. If you pushed commits from another machine and your local clone has not been fetched, those commits will not appear. Add git fetch --quiet to the script before running the log query.

5. Forgetting to include non-coding work. An automated report that shows 15 hours of commits when you worked 40 hours that week tells an incomplete story. Always supplement the generated report with non-commit activities: code reviews, meetings, design sessions, incident response. The automation handles 60 to 80 percent; the human adds the rest.

FAQ

Can I generate team-wide reports with this approach?
Yes. Remove the --author filter and group by author in the output. For teams of five or more, the script output becomes long and is better processed with AI summarization or a dedicated tool that aggregates and formats team reports automatically.

How do I align the report with Jira or Linear tickets?
If your branch names or commit messages include ticket IDs (e.g., PROJ-123), parse them in the script and group commits by ticket. This produces a report that maps directly to your project management tool, making it easy for managers to cross-reference progress against planned work.

What if I work on a monorepo?
Filter commits by directory path: git log -- services/search/ services/checkout/. Map each directory to a project name in your script. This gives you per-service breakdowns within a single repository.

Can I export the report as PDF or HTML?
The markdown output can be converted to PDF with pandoc (pandoc report.md -o report.pdf) or to HTML with any markdown renderer. For polished client-facing reports, use a template with your company branding and pipe the generated content into it.

How do I handle weeks where I was on PTO for part of the week?
The script only shows days with commits, so partial weeks are handled naturally. If you worked Monday through Wednesday and took Thursday-Friday off, the report will show three days of activity. Add a note at the top: "PTO Thursday-Friday" so the reader understands the reduced output.

Final Recommendation

Set up the basic collection script this week and run it manually on Friday. Compare the output to whatever weekly report you would have written by hand. The automated version will be more complete, it will not forget the commits you made on Monday, and it will take one minute to review instead of 20 minutes to write.

Once you trust the output, schedule it with cron and add Slack delivery if your team uses async reporting. For teams that need accurate hours or client-facing reports, layer on IDE-based tracking to replace the timestamp estimates with real measurements. The end state is a weekly reporting pipeline that runs on autopilot: the data is collected continuously, the report is generated on schedule, the developer reviews and approves in under two minutes, and the result is more accurate than anything produced from memory.