Recent launches are easy to remember. Maintenance work, old client projects and slow handovers are easier to miss. A contribution calendar gives you dates to check against release notes, tickets and your own memory.
1. Gather dates from each source
Import the history visible on GitHub and GitLab. Then scan local repositories that never reached either provider. Leave unknown periods blank until you find a source for them.
If the GitHub graph looks incomplete, review what GitHub contribution history can and cannot show.
2. Look for patterns across the calendar
Start with a few concrete questions:
- Which projects account for the longest stretches of sustained attention?
- When did activity move from one repository or organization to another?
- Were intense periods followed by maintenance, exploration or a real break?
- Which work appears only in private or local sources?
3. Add the missing context
A timeline supplies dates and project names. For each period, write down the problem you were solving, your role, the trade-off that took time and what changed after the work shipped.
Use the graph to find dates. Commit totals are poor measures of difficulty or impact.
4. Write the review
- Write one sentence about the main change in your work that year.
- Group projects by period or goal. Use as many sections as the year needs.
- Name the repositories and active months that helped you remember each section.
- Describe what changed after the work shipped.
- End with one practice to continue and one habit to drop.
5. Avoid the vanity-metric trap
Commit totals mostly describe repository activity. Reviews, design work, incident response and mentoring may leave little Git history. Use counts to locate busy periods, then check what happened in the project.
Read how Gitrospective assembles the archive or open the fictional account to see the annual view.