How to Turn Git Commits into a Daily Standup Summary

You can generate a daily standup summary from yesterday's git commits in seconds using git log --since="yesterday" --author="Your Name". Add a shell alias or a short script and you will never scramble to remember what you worked on when standup starts. For a summary that also covers debugging, code reviews, and cross-project work, layer on IDE activity tracking.

Why This Matters

Every developer has experienced the same moment: standup starts, it is your turn, and you cannot remember what you did yesterday. You stall with "I was working on the API thing" while mentally scanning through a blur of branches, Slack threads, and pull requests. By the time you piece together a coherent update, standup has moved on and your summary was vague at best.

This happens because human memory is bad at reconstructing sequences of technical work. You remember the hard bug you fixed and the PR that took forever to get approved, but you forget the three other commits you made, the migration you wrote, and the test you added. The result is that standups are dominated by recency bias: whatever you touched last or whatever caused frustration gets mentioned, while steady, productive work disappears.

Your git log has none of these problems. It remembers everything, in order, with timestamps. A one-line command gives you a complete list of what you committed since the previous day. The only question is how to format it into something you can read aloud in 30 seconds.

Short Answer

Add a shell alias that runs git log --since="yesterday" --author="$(git config user.name)" --format="- %s". Run it before standup. You get a bullet list of commit messages ready to read. For multi-repo workflows, wrap it in a loop. For a fully automated daily digest that includes time spent and non-commit activity, use an IDE plugin like CodeClocker.

Step-by-Step

1. The One-Liner That Replaces Your Memory

This single command gives you yesterday's commits as a clean bullet list.

git log --since="yesterday" --author="$(git config user.name)" \
  --format="- %s" --reverse

Output at 9 AM Tuesday:

- Add database index on orders.customer_id for query performance
- Implement order search endpoint with pagination
- Write integration tests for order search filtering
- Fix null pointer in order status transition logic

That is your standup update. Read it as-is or summarize: "Yesterday I worked on the order search feature. Added the search endpoint with pagination, wrote tests, and fixed a null pointer in the status transitions."

2. Create a Shell Alias for Instant Access

Add this to your ~/.bashrc, ~/.zshrc, or shell config file so the command is always one word away.

# Daily standup summary from git
alias standup='git log --since="yesterday" --author="$(git config user.name)" \
  --format="- %s (%ar)" --reverse'

# Monday variant (covers Friday through Sunday)
alias standup-monday='git log --since="last friday" --author="$(git config user.name)" \
  --format="- %s (%ar)" --reverse'

Now type standup in any git repo before your meeting. The %ar adds relative timestamps ("18 hours ago," "yesterday") so you can see the sequence without mental math.

Output on a Monday morning:

- Refactor payment retry logic to use exponential backoff (3 days ago)
- Add unit tests for backoff timing calculations (3 days ago)
- Update payment gateway error handling for new API version (2 days ago)

3. Cover Multiple Repositories

Most developers touch more than one repo in a day. This script scans all your project directories and assembles a combined standup summary.

#!/bin/bash
# Save as ~/bin/standup.sh and chmod +x

AUTHOR="$(git config user.name)"
SINCE="yesterday"

# Adjust for Monday
if [ "$(date +%u)" -eq 1 ]; then
  SINCE="last friday"
  echo "## Weekend + Friday commits"
else
  echo "## Yesterday's commits"
fi
echo ""

for repo in ~/projects/*/; do
  if [ -d "$repo/.git" ]; then
    commits=$(git -C "$repo" log --author="$AUTHOR" --since="$SINCE" \
      --format="- %s" --reverse 2>/dev/null)
    if [ -n "$commits" ]; then
      project=$(basename "$repo")
      echo "**$project:**"
      echo "$commits"
      echo ""
    fi
  fi
done

Output:

## Yesterday's commits

**billing-api:**
- Implement invoice PDF generation with custom templates
- Add support for multi-currency invoice line items
- Fix tax calculation rounding for EUR transactions

**admin-dashboard:**
- Add invoice preview modal component
- Connect PDF download button to billing API endpoint

Five commits across two repos, organized by project. That translates to a standup update like: "Yesterday I worked on invoice generation in the billing API, including multi-currency support and a tax calculation fix. On the dashboard side, I added the invoice preview modal and hooked up the PDF download."

4. Format for Async Standups in Slack or Teams

Many distributed teams run async standups where you post your update in a channel. This script formats the output for Slack with the standard "yesterday/today/blockers" structure.

#!/bin/bash
AUTHOR="$(git config user.name)"
SINCE="yesterday"
[ "$(date +%u)" -eq 1 ] && SINCE="last friday"

echo "*Yesterday:*"
for repo in ~/projects/*/; do
  if [ -d "$repo/.git" ]; then
    commits=$(git -C "$repo" log --author="$AUTHOR" --since="$SINCE" \
      --format="- %s" --reverse 2>/dev/null)
    if [ -n "$commits" ]; then
      echo "$commits"
    fi
  fi
done

echo ""
echo "*Today:*"
echo "- (fill in your plan)"
echo ""
echo "*Blockers:*"
echo "- None"

Output ready to paste into Slack:

*Yesterday:*
- Implement invoice PDF generation with custom templates
- Add support for multi-currency invoice line items
- Fix tax calculation rounding for EUR transactions
- Add invoice preview modal component
- Connect PDF download button to billing API endpoint

*Today:*
- (fill in your plan)

*Blockers:*
- None

You fill in the "today" section manually (git cannot predict the future, unfortunately) and update blockers if applicable. The "yesterday" section is generated automatically with zero recall effort.

5. Add Context with IDE Activity Tracking

The scripts above solve the "what did I commit" problem. They do not solve the "what else did I do" problem. Yesterday you might have spent an hour debugging a production issue that ended with a one-line config change, 45 minutes reviewing two pull requests, and 30 minutes in a design sync. None of this appears in your git log, but all of it is legitimate work worth mentioning in standup.

An IDE plugin like CodeClocker records your development sessions continuously. It knows which projects and files you worked on, how long each session lasted, and which commits were produced during that time. Its daily digest includes both the deliverables (commits) and the effort (active coding hours by project), giving you a complete picture you can reference at standup without maintaining a separate log.

Example

Here is what the standup preparation looks like in practice for a developer on a four-person team.

9:00 AM, standup starts in 5 minutes. Marcus opens his terminal and runs standup.

Git output:

**payment-service:**
- Add webhook retry mechanism with exponential backoff
- Fix duplicate webhook delivery on timeout

**shared-libs:**
- Update HTTP client to support configurable retry policies

What Marcus says at standup: "Yesterday I finished the webhook retry mechanism in the payment service. Fixed a bug where timeouts were causing duplicate deliveries. I also updated the shared HTTP client to support configurable retries since we'll need that pattern in other services too. Today I'm starting on the webhook event logging. No blockers."

What the git log missed: Marcus spent 40 minutes in the morning reviewing Elena's PR for the subscription cancellation flow. He spent 20 minutes helping a junior developer debug a Docker networking issue. He also attended a 30-minute incident debrief about last week's payment outage. None of this produced commits, but all of it was valuable team work. If Marcus had wanted to mention these, he would have needed to remember them himself or check his calendar and Slack history.

With IDE tracking, Marcus would also see: 4.2 hours active coding (payment-service: 2.8h, shared-libs: 1.4h). This confirms his git activity and gives him confidence that the three commits represent a solid day of focused work, not just three quick changes.

Common Mistakes

1. Reading commit messages verbatim in standup. Commit messages are written for developers reviewing code history. They are too granular and too technical for a standup audience. "Fix null pointer exception in OrderStatusTransition.validateState when order has no payment method" becomes "Fixed a bug in the order status transitions." Summarize for your audience.

2. Only reporting commits from the main branch. If you worked on a feature branch all day but did not merge, your commits exist but are not on main. Make sure your git log command runs against the current branch or uses --all to include all branches. Otherwise you will see an empty result and think you did nothing.

3. Forgetting the Monday problem. --since="yesterday" on Monday means "since Sunday," which usually returns nothing because most people do not commit on Sundays. Use --since="last friday" on Mondays, or build the check into your script as shown in Step 3.

4. Not accounting for timezone mismatches. If your git config timezone differs from your local timezone, the "yesterday" boundary might not align with your actual workday. A developer in UTC+9 using a repo configured for UTC might see today's morning commits mixed with yesterday's, or miss afternoon commits that git thinks belong to the "next day." Check your git config with git log --format="%ad" --date=local -1 to verify timestamps match your expectations.

5. Skipping non-coding contributions. Standups are about team coordination, not commit counts. If you spent three hours reviewing pull requests, debugging someone else's issue, or writing a design document, say so. The fact that git does not capture it does not mean it is not worth reporting. Use the git output as a foundation, then add the human context.

FAQ

Can I automate posting my standup to Slack every morning?
Yes. Combine the Slack-formatted script with a cron job and a Slack webhook. Set it to run at 8:55 AM and post to your standup channel. The "yesterday" section is automated; you can edit the "today" section via Slack afterward. For a managed version of this, tools like CodeClocker can push daily digests to team channels without custom scripting.

What if I have a bad commit message habit?
If your commits say "fix," "wip," or "stuff," your standup summary will be useless. This is a good forcing function to improve commit messages. Use the convention: start with an imperative verb ("Add," "Fix," "Refactor," "Update") followed by what changed and why. Good commit messages serve double duty as standup notes and code review context.

How does this work with squash merges?
If your team squashes feature branches on merge, the detailed commit history is replaced with a single merge commit. Run your standup command against the feature branch before merging, or configure your merge workflow to preserve the commit list in the squash commit body. Some teams use git merge --squash with a message template that lists the original commits.

What about days when I only did code reviews?
Your git log will be empty, which is fine. Mention the reviews by name: "Yesterday I reviewed PRs #312 and #318 for the notification feature, and spent the afternoon debugging the staging deployment issue." Git is a starting point, not the whole story. You can pull review activity from GitHub with gh pr list --search "reviewed-by:@me updated:>=yesterday" to supplement.

Does this replace standup tools like Geekbot or Standup.ly?
For solo developers or small teams, a shell alias is simpler and free. For larger teams that need aggregated reports, reminders, and async standup management, a dedicated tool adds value. The git-based approach works best as the "yesterday" section of whatever standup format you already use.

Final Recommendation

Add the standup alias to your shell config today. It takes 30 seconds to set up and saves you from the daily mental scramble of reconstructing yesterday's work. If you write clear commit messages, this one alias will make your standup updates more accurate and specific than 90 percent of what your teammates are saying from memory.

For teams that want to go further, pair the git-based summary with an IDE tracker that captures active coding time and non-commit activity. The combination means nobody on the team has to remember what they did, every standup update is backed by data, and the information is available for async teams who post updates rather than meeting live. The goal is not to replace the human conversation in standup but to eliminate the memory tax that makes the conversation vague.