Weekly Git Summary: Turn Commits into a Team Update

A weekly git summary takes your team's raw commit history and condenses it into a readable update: what was built, what was fixed, and what is in progress. You can generate one with a git log command and some formatting, pipe it through an AI for plain-language rewriting, or use an IDE-based tool that combines commit data with actual coding hours to produce summaries automatically.

Why This Matters

Every Monday, someone on your team is asked some version of the same question: "What did we accomplish last week?" The answers come from memory, Jira ticket titles, or a quick scroll through Slack. They are incomplete, inconsistent, and take 15 to 30 minutes per person to assemble.

Meanwhile, the git history already contains a precise, timestamped record of every change your team made. The problem is that git log output is designed for developers debugging code, not for managers reading sprint updates or clients reviewing progress. The commit messages are too granular ("fix null check in OrderValidator"), the format is wrong (reverse-chronological with hashes and diffs), and the context is missing (which project, which ticket, how many hours).

A weekly git summary bridges this gap. It takes the raw material that already exists and reshapes it into something the rest of the organization can use: a team update for the Monday standup, a sprint summary for the retrospective, or a progress report for the client.

Short Answer

Run git log --since="last monday" --format="%an | %ad | %s" to extract the raw data. Group commits by author and topic, then rewrite the technical messages into plain-language summaries. For automation, pipe the output into an LLM or use a tool like CodeClocker that generates team-level weekly summaries from IDE activity and commit history with actual hours attached.

Step-by-Step

1. Extract the Raw Weekly History

Start by pulling the full team's commit history for the past week into a structured format. Include the author, timestamp, and commit message so you can group and attribute work later.

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

This produces one line per commit:

Alice Chen|2026-04-20 09:15|Add database migration for user preferences
Alice Chen|2026-04-20 11:30|Implement preference API endpoints
Alice Chen|2026-04-20 14:45|Add unit tests for preference validation
Bob Park|2026-04-20 10:00|Fix memory leak in WebSocket connection pool
Bob Park|2026-04-20 13:20|Update connection pool metrics dashboard
Bob Park|2026-04-21 09:30|Refactor session cleanup to use TTL-based expiry
Alice Chen|2026-04-21 10:15|Wire preference panel into settings page
Alice Chen|2026-04-21 15:00|Fix timezone handling in preference date fields
Bob Park|2026-04-22 09:00|Add circuit breaker for external payment gateway
Bob Park|2026-04-22 14:30|Write load test for connection pool under 10k sessions

For teams working across multiple repositories, loop through them:

#!/bin/bash
SINCE="last monday"

for repo in ~/projects/*/; do
  [ -d "$repo/.git" ] || continue
  project=$(basename "$repo")
  git -C "$repo" log --since="$SINCE" \
    --format="$project|%an|%ad|%s" \
    --date=format:"%Y-%m-%d %H:%M" \
    --reverse 2>/dev/null
done

2. Group and Summarize by Author and Topic

Raw commit lists are not summaries. A summary groups related commits into logical units and describes what was accomplished, not what was changed line by line.

You can do this manually with a simple script that groups by author:

#!/bin/bash
SINCE="last monday"

echo "# Weekly Git Summary - $(date +%Y-%m-%d)"
echo ""

git log --since="$SINCE" --format="%an" | sort -u | while read author; do
  echo "## $author"
  git log --since="$SINCE" --author="$author" \
    --format="- %s" --reverse
  echo ""
done

This produces a per-developer breakdown:

# Weekly Git Summary - 2026-04-24

## Alice Chen
- Add database migration for user preferences
- Implement preference API endpoints
- Add unit tests for preference validation
- Wire preference panel into settings page
- Fix timezone handling in preference date fields

## Bob Park
- Fix memory leak in WebSocket connection pool
- Update connection pool metrics dashboard
- Refactor session cleanup to use TTL-based expiry
- Add circuit breaker for external payment gateway
- Write load test for connection pool under 10k sessions

This is better than a flat commit list, but still too granular for a team update. The next step turns these into readable summaries.

3. Rewrite for a Non-Technical Audience with AI

Feed the grouped output to an LLM with a prompt that asks for team-update-style summaries:

#!/bin/bash
SINCE="last monday"

LOG=$(git log --since="$SINCE" \
  --format="%an|%ad|%s" --date=format:"%Y-%m-%d %H:%M" \
  --stat --reverse)

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-sonnet-4-6\",
    \"max_tokens\": 2048,
    \"messages\": [{
      \"role\": \"user\",
      \"content\": \"Generate a weekly team summary from these git commits. Group by person, then by topic. For each topic: one plain-language sentence describing what was accomplished, and a tag (Feature / Bug Fix / Infra / Docs). Write for a project manager, not a developer. Keep it concise.\n\n${LOG}\"
    }]
  }" | jq -r '.content[0].text'

The AI transforms the raw commits into a team-readable update:

# Weekly Team Summary - April 20-24, 2026

## Alice Chen
- **User Preferences** (Feature): Built the full user preferences system,
  from database schema through API endpoints to the frontend settings panel,
  including validation and timezone-aware date handling.
- **Timezone Fix** (Bug Fix): Corrected a date display issue in the new
  preference panel that affected users outside UTC.

## Bob Park
- **Connection Pool Stability** (Bug Fix / Infra): Fixed a memory leak in the
  WebSocket connection pool and refactored session cleanup to use TTL-based
  expiry instead of manual sweeps. Added monitoring dashboards for pool metrics.
- **Payment Gateway Resilience** (Infra): Added a circuit breaker pattern for
  the external payment gateway to prevent cascading failures during outages.
- **Load Testing** (Infra): Wrote load tests validating the connection pool
  handles 10,000 concurrent sessions without degradation.

Alice's five commits became two line items. Bob's five became three. The technical details are preserved but rewritten for a non-developer audience. This is a summary you can paste directly into a Slack channel, sprint review deck, or client email.

Example

Here is a full before-and-after for a three-person team working across two repositories.

Input: Raw git log from two repos

[backend] Alice Chen|2026-04-20 09:15|Add GraphQL schema for notification preferences
[backend] Alice Chen|2026-04-20 14:00|Implement notification preference resolvers
[backend] Alice Chen|2026-04-21 09:30|Add email digest scheduling based on preferences
[backend] Bob Park|2026-04-20 10:30|Fix N+1 query in team members endpoint
[backend] Bob Park|2026-04-21 11:00|Add database index for team lookup queries
[backend] Bob Park|2026-04-22 09:00|Migrate legacy team permissions to RBAC model
[frontend] Carol Wu|2026-04-20 10:00|Add notification settings page with toggle controls
[frontend] Carol Wu|2026-04-21 13:00|Implement email digest preview component
[frontend] Carol Wu|2026-04-22 09:30|Fix accessibility issues in notification toggles
[frontend] Carol Wu|2026-04-22 14:00|Add keyboard navigation for settings panels

Output: AI-generated weekly team summary

# Weekly Team Summary - April 20-22, 2026

## Alice Chen (backend)
- **Notification Preferences** (Feature): Built the backend for user
  notification preferences, including GraphQL schema, resolvers, and
  automated email digest scheduling based on user settings.

## Bob Park (backend)
- **Team Query Performance** (Bug Fix): Fixed a slow query on the team
  members page and added a database index, reducing load time significantly.
- **Permissions Migration** (Infra): Migrated the legacy team permissions
  system to a role-based access control (RBAC) model.

## Carol Wu (frontend)
- **Notification Settings UI** (Feature): Built the notification settings
  page with toggle controls and an email digest preview, allowing users
  to configure their notification preferences from the dashboard.
- **Accessibility Improvements** (Bug Fix): Fixed screen reader and keyboard
  navigation issues in the notification settings panels to meet WCAG standards.

---
**Highlights:** Notification preferences feature shipped end-to-end
(backend + frontend). Team query performance improved. RBAC migration
completed.

What the AI inferred correctly: Ten commits across two repos were grouped into five summary items across three developers. The AI recognized that Alice's backend work and Carol's frontend work were part of the same notification preferences feature and noted it in the highlights. Bob's query fix and index addition were grouped as a single performance item. Carol's accessibility commits were consolidated.

What required manual review: The summary does not include hours. Alice spent roughly 4 hours on the notification backend, but the AI has no way to know that without time tracking data. Carol's accessibility work took an entire afternoon of testing with screen readers, but appears as a one-line item. A manager reading this summary gets an accurate picture of what was done, but not how long it took. For time-aware summaries, you need IDE-level tracking that captures actual development sessions alongside the commit history.

Common Mistakes

1. Listing every commit as a separate line item. A weekly summary with 47 bullet points is not a summary. Group related commits into logical tasks. If three commits all touch the same feature, they are one line item in the summary, not three. The purpose is to communicate what was accomplished, not to reproduce the git log in a different font.

2. Using commit messages as-is for non-technical audiences. "Refactor useEffect cleanup in NotificationProvider" means nothing to a product manager. Rewrite it: "Fixed a bug where notification preferences were not saved correctly when navigating away from the settings page." The technical detail belongs in the commit message. The summary needs the business outcome.

3. Only covering committed code. A weekly summary that only includes commits misses code reviews, architecture discussions, debugging sessions, documentation, and mentoring. If your summary shows Alice made 3 commits on Tuesday and nothing on Wednesday, the reality might be that Wednesday was spent in design review and code review with no commits. Mention non-commit work or use a tool that tracks it automatically.

4. Generating the summary once and never iterating on the format. The first summary you generate will not match what your team actually needs. Share it, get feedback, adjust the prompt or script. Does the PM want ticket numbers? Add them. Does the client want hours? Add time tracking. Does the team lead want a "blockers" section? Add a prompt instruction for it. Treat the format as a living template.

5. Not attributing work to individuals. A flat list of accomplishments with no author attribution makes it impossible for managers to understand capacity, identify bottlenecks, or give credit. Always group by person first, then by topic within each person. Team-level highlights can go at the end as a separate section.

FAQ

How do I include work from multiple git repositories?
Loop through each repo directory and prefix each commit with the project name. The script in Step 1 above handles this. If your repos are on a remote server, use the GitHub or GitLab API to fetch commit history instead of local git commands.

Can I post the summary directly to Slack or email?
Yes. Pipe the AI output to a Slack webhook or email CLI. For Slack: curl -X POST -H 'Content-type: application/json' --data "{\"text\": \"$SUMMARY\"}" $SLACK_WEBHOOK_URL. Schedule it with cron to run every Friday afternoon and your team gets the summary without anyone writing it.

How do I add hours to the summary?
Git commits have timestamps but not durations. You can estimate hours from the gaps between commits, but these estimates are unreliable (lunch breaks, meetings, and context-switching create false gaps). For accurate hours, pair the summary with IDE-based time tracking from a tool like CodeClocker, which records actual coding sessions and maps them to commits and projects.

Should the summary include work-in-progress or only merged code?
It depends on your audience. For client-facing reports, include only merged or deployed work. For internal team updates, include in-progress work to give visibility into what is being actively developed. Add a flag to your git log command: use --merges for merged-only, or include all branches for a full picture.

What if team members have inconsistent commit message styles?
This is the most common obstacle to useful git summaries. The AI can compensate for some inconsistency, but "fix stuff" and "wip" commits produce poor summaries regardless of the tool. Establish a minimal convention: start with a verb, mention the feature area, reference the ticket number. Even loose adherence to this pattern dramatically improves summary quality.

Final Recommendation

Start with the shell script from Step 2: a simple per-author commit list generated every Friday. Share it with your team for one or two weeks to establish the habit and identify what is missing. Then add the AI rewriting step from Step 3 to turn the raw commits into plain-language summaries. Automate delivery to Slack or email with a cron job.

If the summaries need hours — for billing, sprint velocity, or capacity planning — add IDE-based time tracking. The combination of real-time coding session data and AI-powered commit summarization produces weekly updates that are accurate, complete, and require zero manual effort from developers. The git history provides the what, the IDE tracking provides the how long, and the AI provides the translation into language the rest of the organization can act on.