"What Did I Do Yesterday?" — Use Git Commits to Build Your Standup Update

Run git log --since="yesterday" --author="$(git config user.name)" --format="- %s" --reverse and you have an instant answer. Every commit you made since yesterday appears as a bullet point, in order, with the exact messages you wrote. No more staring at the ceiling trying to reconstruct your day while four teammates wait on Zoom.

Why This Matters

It is 9:01 AM. Standup has started. Someone finishes their update and the facilitator says your name. Your brain scrambles. You know you wrote code all day. You remember something about an API. There was definitely a bug fix. But was that yesterday or the day before? Did you finish the tests or just start them?

This happens to every developer, every week. It is not a memory problem. It is a context problem. Between yesterday's work and right now, you slept, showered, checked email, read Slack, maybe looked at a different codebase, and your brain has overwritten yesterday's working context with today's. The details are gone.

But they are not really gone. They are sitting in your git history, timestamped and attributed to you, waiting to be read. One command retrieves them. The gap between "I have no idea" and "here is exactly what I did" is a single terminal command that takes less than a second to run.

Short Answer

Open your terminal in any git repo and run:

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

This gives you a chronological bullet list of every commit you made since yesterday. Read it, summarize it in two sentences, and you have your standup update. For a permanent setup, add it as a shell alias called standup. For a version that includes time tracking and non-commit activity, use an IDE plugin like CodeClocker.

Step-by-Step

1. The Instant Answer: One Command

Copy this into your terminal right now:

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

What each flag does:

• --since="yesterday" filters to commits after midnight yesterday
• --author="$(git config user.name)" shows only your commits
• --format="- %s" outputs each commit as a markdown bullet with the message
• --reverse puts them in chronological order (oldest first)
• --all includes all branches, not just the one you are currently on

Output:

- Set up test fixtures for payment retry logic
- Implement exponential backoff for failed charges
- Add circuit breaker for Stripe API timeouts
- Write integration tests for retry with mocked failures
- Update error handling to distinguish retryable vs terminal errors

That is five commits. At standup you say: "Yesterday I built the payment retry system with exponential backoff and a circuit breaker for Stripe timeouts. Wrote integration tests and cleaned up the error handling to separate retryable from terminal failures." Done. Fifteen seconds of reading replaced two minutes of guessing.

2. Make It Permanent: Shell Alias

Add this to your ~/.zshrc or ~/.bashrc so you never have to type the full command again:

# What did I do yesterday?
yesterday() {
  local since="yesterday"
  # On Monday, look back to Friday
  [ "$(date +%u)" -eq 1 ] && since="last friday"
  git log --since="$since" --author="$(git config user.name)" \
    --format="- %s" --reverse --all
}

Now type yesterday before every standup. On Mondays it automatically looks back to Friday so your weekend does not create a blind spot.

3. Check All Your Repos at Once

If you touched multiple repos yesterday, checking each one separately is tedious. This script scans all of them:

#!/bin/bash
# Save as ~/bin/yesterday and chmod +x

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

echo "What I did since $SINCE:"
echo ""

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

[ "$found" -eq 0 ] && echo "No commits found. Either you took the day off or you need to check other directories."

Output:

What I did since yesterday:

**checkout-service:**
- Implement exponential backoff for failed charges
- Add circuit breaker for Stripe API timeouts
- Write integration tests for retry with mocked failures

**shared-config:**
- Update timeout defaults for payment service connections

4. Add Timestamps for Extra Context

Sometimes knowing when you did something matters, for example, to confirm you worked on a specific feature before or after a meeting.

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

Output:

- Set up test fixtures for payment retry logic (20 hours ago)
- Implement exponential backoff for failed charges (18 hours ago)
- Add circuit breaker for Stripe API timeouts (16 hours ago)
- Write integration tests for retry with mocked failures (15 hours ago)
- Update error handling to distinguish retryable vs terminal errors (14 hours ago)

The relative timestamps (%ar) tell you at a glance that you started around 9 AM and your last commit was around 3 PM. Useful for reconstructing the flow of your day if someone asks follow-up questions.

5. See the Full Picture with IDE Tracking

Git commits answer "what did I ship." They do not answer "what else did I do." Yesterday you probably also:

• Spent 30 minutes reading the Stripe documentation before writing the retry logic
• Reviewed a teammate's pull request for 45 minutes
• Debugged a test environment issue that required no code changes
• Attended a 20-minute design sync

None of this shows up in git log. For most standups, the commit list is enough because you can add the non-coding highlights verbally. But if you want a complete daily summary without any memory effort at all, an IDE plugin like CodeClocker tracks your active development time, links it to the commits you produce, and generates a daily digest that covers both the output (commits) and the input (hours worked per project).

Example

The scenario: It is Wednesday morning. You open your terminal and type yesterday.

What your terminal shows:

What I did since yesterday:

**user-service:**
- Add email verification flow for new account registration
- Implement rate limiting on verification email endpoint
- Fix race condition in concurrent verification attempts

**admin-dashboard:**
- Add user verification status to admin user list view

What you say at standup: "Yesterday I built the email verification flow for new registrations, including rate limiting and a fix for a race condition when users click verify multiple times. Also added the verification status column to the admin dashboard. Today I'll connect the verification to the onboarding flow and write the email templates. No blockers."

Time spent: Zero seconds remembering. Five seconds reading the output. Ten seconds formulating the summary. The whole thing took less time than the pause most people take before saying "ummm, so yesterday I was working on..."

What the command missed: You spent 40 minutes yesterday helping a new team member set up their local environment and 25 minutes in a sprint refinement meeting. Both are worth mentioning if relevant, and both required you to remember them yourself. The git output handled the hard part (the four coding deliverables), leaving you to supplement with two easy-to-remember items.

Common Mistakes

1. Running the command on the wrong branch. Without --all, you only see commits reachable from your current branch. If you were on feature/email-verification yesterday but switched to main this morning, yesterday's commits are invisible. Always use --all.

2. Forgetting Monday is different. --since="yesterday" on Monday means Sunday, not Friday. Your script must detect Monday and look back to Friday. Every standup script that lacks this check produces a blank output on 20 percent of workdays.

3. Having useless commit messages. If your commits say "fix," "wip," "asdf," or "save progress," the output is worthless. The command reveals exactly what you wrote, and if what you wrote is garbage, the summary is garbage. Good commit messages are an investment that pays off every standup morning. Use the format: <imperative verb> <what changed>.

4. Only checking one repo when you worked in several. If you committed to three repos yesterday but only run the command in one, you will underreport two-thirds of your work. Use the multi-repo script or make a habit of running the command in each project directory.

5. Treating the output as your entire contribution. Commits are the visible artifacts of coding work. They are not the totality of what you contributed to the team. Code reviews, debugging, mentoring, meetings, and planning are all real work that deserves mention when relevant. Use the git output as the backbone of your update and add the human context on top.

FAQ

What if I had zero commits yesterday?
That happens. Maybe you spent the day in meetings, reviewing PRs, or debugging an issue that turned out to be a configuration problem. The empty git output is actually useful information: it tells you that today's standup update needs to come entirely from memory or from other tools. For days like this, a quick end-of-day note to yourself ("reviewed PRs #245 and #251, attended architecture sync, debugged staging DNS issue") takes 30 seconds and saves you from the blank-mind moment tomorrow.

Can I use this to check what a teammate did?
Yes. Replace $(git config user.name) with their name: --author="Jane Smith". This is useful for tech leads doing async check-ins, preparing for one-on-ones, or understanding what happened while you were out. It is not a surveillance tool; it just reads the same public commit history that everyone on the team already has access to.

What about commits I made on another machine?
If you pushed those commits and your local repo is up to date, they will appear. If you forgot to push, they only exist on the other machine. Run git fetch before the standup command if you work from multiple machines, or use the origin/ remote refs to include pushed-but-not-pulled commits.

Does this work if my team squashes commits on merge?
Squash merges collapse your commit history into a single merge commit. If your branch was merged yesterday via squash, the original commits disappear from the main branch. Run the command before merging or against the feature branch directly. Alternatively, use --all which includes commits on branches that have not been merged yet.

How is this different from checking GitHub's contribution graph?
The contribution graph shows that you committed on a given day. The git log command shows exactly what you committed, with messages, in order. It is the difference between "yes I worked" and "here is what I built." For standup, you need the latter.

Final Recommendation

Add the yesterday function to your shell config right now. It takes 30 seconds. Tomorrow morning, run it before standup and read the output. You will give a more specific, more accurate update than you have given in months, and it will take less effort than your usual approach of staring at the ceiling and hoping your memory cooperates.

For most developers, this one function is enough. If you work across many repos, add the multi-repo wrapper. If you want to eliminate standup prep entirely, including the non-commit activities that the git command misses, use an IDE tracker that generates the daily summary for you. But start with the command. It solves the core problem, it is free, and it works right now.

Related Reading

• Git Commit Summary for Standup: A Better Way to Prepare Daily Updates
• How to Turn Git Commits into a Daily Standup Summary
• Auto-Generate a Standup Report from Git History
• How to Generate a Timesheet from Git Commits