How to turn your GitHub commits into resume bullets
Updated October 17, 2026
When it's time to update their resume, most developers write from memory and forget half of what they did. But the record already exists: every commit has a date, a repository and a change, and most pull requests explain why. It's the best source you have for concrete bullets.
Why commits are your best source
Memory is selective: you remember the last project and forget the hard migration from two years ago. Your history doesn't forget. It shows what you worked on, when, and how much.
Pull requests are even better, because the description usually covers the problem, the fix and sometimes the result ("p95 dropped from 800 ms to 120 ms"). That's practically a finished bullet.
What to look for in your history
Go through the repositories from each job and flag commits and PRs that fall into these groups:
- Features that reached users ("feat: one-click checkout").
- Performance and cost: words like optimize, cache, reduce, index, batch.
- Reliability: incident fixes, retries, idempotency, monitoring.
- Migrations and architecture changes: new database, new framework, splitting a service.
- Quality and delivery: tests, CI/CD, build time, automation.
- Themes that run for weeks: they're usually a whole project and deserve a bullet of their own.
From many commits to one bullet
A bullet isn't a commit. Group related commits into one accomplishment and answer two questions: what was the problem before? What changed afterwards? Then write it as action verb + what + tool + result.
feat: export queue · fix: export timeout · perf: export in batches of 500 · test: async export
Made catalog export asynchronous with queues and 500-item batches, ending timeouts for stores with 5,000+ products.
Numbers: only the ones you can back up
Look for numbers in PR descriptions, tickets, monitoring dashboards or your own notes. If there's no number, describe the effect without inventing one: "ending timeouts" is already a result.
A made-up number is the fastest way to lose an offer in the technical interview, when someone asks "how did you measure that?".
Private and company repositories
You don't need to show code to use your history. The bullet describes the work; it doesn't expose the repository. Just leave out internal names, customer data and figures your company treats as confidential.
If the repository lives on a company laptop or another host (GitLab, Bitbucket, Azure DevOps), local git has the history: git log --author="you@email" already shows what's yours.
Each accomplishment under the right role
If you held more than one role at the same company, use commit dates to split the work by period. It makes your growth visible: what you did as a mid-level engineer and what you took on as a senior.