How to Use Your Git History to Ace Your Next Performance Review

Every six months, engineers across the world try to remember what they did at work. They scroll through Slack, dig through Jira, scan their calendar — and still end up writing something vague and incomplete.

The irony is that most of them have a perfect, timestamped record of their work sitting in plain sight: their git history.

Here's how to use it properly.

Why your git history is the best evidence you have

Git commits are honest in a way that other records aren't. Jira tickets get closed without being updated. Slack messages disappear or lack context. Your memory is subject to recency bias and selective recall.

Your commits, by contrast:

• Are timestamped to the minute
• Are attached to real code that shipped
• Reference specific repos, features, and fixes
• Give you a complete picture across the full review period — not just the last two weeks

The challenge isn't finding the evidence. It's translating commits into language that means something to a non-technical reviewer.

How to pull your commit history for a review period

For a typical six-month review period, you want all commits authored by you between two dates. In git:

git log --author="Your Name" --after="2025-07-01" --before="2026-01-01" --oneline

If you work across multiple repos, you'll need to run this in each one. Filter out the noise:

• Merge commits (--no-merges)
• Dependency bumps (anything from Dependabot or Renovate)
• Reverts without a corresponding explanation

What's left is your real work.

Grouping commits into themes

Raw commits are too granular to put directly into a review. You need to cluster them into meaningful themes — projects, initiatives, or types of work.

Common patterns to look for:

• A project arc: commits in the same repo that span several weeks and share a theme (e.g. "migrate auth to JWT", "ship payments v2")
• Reliability work: commits that fix bugs, improve error handling, or respond to incidents
• Infrastructure work: CI/CD improvements, dependency upgrades, observability additions
• Feature work: commits that clearly correspond to user-facing changes

Each cluster becomes a candidate evidence item for your review.

Translating a commit cluster into a review evidence item

A commit cluster tells you what you did. Your review needs to explain why it mattered. The translation requires one extra step: connecting the technical work to a business or team outcome.

Here's an example. Suppose you have 12 commits across three weeks that all touch the database query layer, with messages like:

• fix: add index to users.email
• perf: batch load account data instead of per-row fetch
• refactor: remove N+1 in dashboard aggregation

The commit messages tell you the technical story. Now add the outcome:

"The dashboard was consistently timing out for accounts with more than 500 records. I identified three separate query inefficiencies — a missing index, an N+1 in the aggregation layer, and a per-row data load that could be batched. After fixing all three, p95 dashboard load time dropped from 8s to 600ms. No further timeout complaints since."

That's a complete evidence item: technical depth, specific actions, measurable outcome.

What to do when commit messages are bad

Not everyone writes great commit messages, and you might be looking at six months of fix stuff and wip. In that case, you have two sources to reconstruct context:

• The diff: git show [sha] shows exactly what changed. Even a poorly-named commit becomes readable when you see what files were touched.
• The PR: Most meaningful commits have an associated pull request with a description, review comments, and often a link to the Jira or Linear ticket. That's where the "why" lives.

Going forward, treat your commit messages as part of your performance review. Conventional commits (feat:, fix:, perf:) make the retrospective analysis significantly easier.

GitHub, GitLab, and Azure DevOps: platform-specific tips

Each platform has features that make commit archaeology easier:

• GitHub: Your profile's contribution graph shows daily commit frequency across all public repos. Your pull requests list at github.com/pulls?q=author:you+created:2025-07-01..2026-01-01 is the most complete view of shipped work.
• GitLab: The "Contribution analytics" page (under a group) breaks down commits, merge requests, and issues by author and date range.
• Azure DevOps: The "My Pull Requests" view and team project history are the most useful starting points.

Common mistakes to avoid

• Listing commits instead of summarising them. Your reviewer doesn't want a commit log. They want a narrative.
• Ignoring review work. If you reviewed 40 PRs in a quarter, that's a meaningful collaboration signal. It won't show in your commits, but it shows in your PR review history.
• Only counting green commits. Commits that fix your own bugs still count. Honest self-awareness in a review ("I introduced a bug in X, caught it in Y, and fixed it in Z") is often better received than a suspiciously perfect record.

Automate the hard part

Manually pulling commits across multiple repos, filtering noise, grouping by theme, and writing SAR-structured evidence takes a couple of hours the first time. It's time well spent — but it's also time that can be compressed significantly with the right tooling.

Gitsprout connects to your GitHub, GitLab, or Azure DevOps account, pulls your commits for any date range, filters out bots and merges, and generates structured performance review evidence across the standard six review categories. What used to take an afternoon now takes about two minutes.

However you approach it — manually or with tooling — the core principle holds: your git history already wrote your performance review. You just need to read it.