How to Track Git Contributions Across Your Team

Why Track Git Contributions?

Engineering teams need visibility into who is doing what across repositories. Without aggregated data, managers rely on gut feeling or manual status updates to understand workload distribution, spot bottlenecks, and recognize high performers.

Tracking git contributions provides an objective, real-time view of engineering activity. It surfaces patterns like uneven review loads, single points of failure in critical repos, and developers who consistently ship but rarely get recognized.

What Data to Collect

Raw commit counts alone paint an incomplete picture. A comprehensive tracking system should capture:

• Commits— code changes pushed to repositories
• Pull requests— code proposed for review and merge
• PR reviews— feedback given on others' code
• Merged PRs— code that actually shipped to production
• Issues— bugs reported and features requested
• Active days— consistency of contribution over time

Weighting these differently gives a more accurate picture of engineering impact. A merged PR typically represents more effort than a single commit. See our guide on git metrics that actually matter.

Methods for Tracking

GitHub API

The GitHub GraphQL API provides contribution data per user, including commit counts, PR activity, and review history. You can query contributions by year and aggregate across repositories. This is the most flexible approach but requires building your own aggregation pipeline.

Git Log Analysis

Running git log locally gives you per-repository commit data. This works for single-repo teams but becomes cumbersome across multiple repositories and does not capture PR reviews or issues.

Automated Tools

Tools like Git Leaderboard automate the entire process: they sync GitHub data, aggregate metrics across all repositories, and present ranked dashboards with historical trends.

Key Challenges

• Private repository visibility — GitHub can include anonymized private contribution counts if enabled in user settings, but repo-level detail stays hidden
• Multi-repo teams— contributions spread across dozens of repositories need aggregation into a single view
• API rate limits— GitHub imposes a 5,000-point hourly limit on GraphQL queries, which caps how much data you can fetch at once
• Fair comparison— different roles produce different activity patterns; a reviewer may have few commits but many reviews