TL;DR: Every major GitHub analytics platform measures commits to the main branch only — which represents roughly 10–20% of where engineering work actually happens. Feature branches contain 3–5× more commits than main during any given period, based on Warclick's analysis of engineering teams across the platform (Q1 2026). Main-branch-only measurement systematically undercounts junior contributors, makes experimental work invisible, and misattributes squash-merged features to the engineer who pressed "merge" rather than those who built them. The fix is all-branch analytics — measuring every commit, every branch, every contributor.
The Blind Spot in Every GitHub Analytics Tool
Here's a question most engineering leaders have never asked: what percentage of your team's work actually reaches your main branch?
If you're like most organizations, the answer is somewhere between 10% and 20%. The rest lives on feature branches, developer branches, release branches, and experiment branches — and your analytics tool has no idea it exists.
A feature branch is a temporary Git branch where engineers build, test, and iterate before merging work into the primary codebase. This is where the actual engineering process unfolds — the commits, the revisions, the code reviews, the back-and-forth, before a polished result reaches main.
Every major GitHub analytics platform on the market today measures one thing: commits to your primary branch. They track what ships to production and call it "developer productivity."
But production commits are the final output of a long pipeline. They're the polished, squashed, merged result of weeks of work that happened elsewhere. Measuring only main branch commits is like judging a restaurant by counting the plates that leave the kitchen while ignoring the prep, the cooking, and the plating that made those dishes possible.
What Lives on Feature Branches (And Why It's Invisible)
Let's be specific about what you're missing.
What percentage of engineering work happens on feature branches?
Feature branches are where engineers spend most of their day. Every new feature, bug fix, refactor, and experiment starts as a branch. Engineers commit dozens of times to these branches, iterating, testing, and refining, before a single line reaches main. Based on Warclick's analysis of engineering teams across the platform in Q1 2026, feature branches contain 3–5× more commits than main during the same time period.
None of it is incidental. It's the core engineering effort. And none of it shows up in main-branch-only tools.
Junior Developer Contributions
New engineers are especially penalized by main-branch-only measurement. A junior developer working on feature/onboarding-revamp might ship 200 commits and participate in dozens of code reviews over their first two months. They're learning the codebase, building features, and becoming productive. But until their branch merges to main — which might take weeks or months for a large feature — they're a ghost in your analytics dashboard.
Their manager's metrics say "low activity." Reality says they're one of the most active contributors on the team. The gap isn't just a measurement problem. It's a morale problem.
Experiments and Prototypes
Your senior architect spent two weeks building a proof-of-concept for a new caching layer on an experimental branch. It influenced a major architecture decision. But the branch was never merged — the experiment served its purpose and was archived.
In main-branch-only analytics, that two weeks of work registers as zero activity. In all-branch analytics, you see the full picture: the commits, the thoughtfulness, the impact on team direction, even though it never shipped.
Squash Merge Attribution
Many teams use squash merging — collapsing an entire feature branch's history into a single commit on main. Squash merging is clean git hygiene, but it destroys attribution. If five engineers contributed to a feature branch and the tech lead merges it with a squash, main-branch-only tools credit all the work to the tech lead.
The four engineers who actually built the feature? Invisible.
What Happens When Leaders Make Decisions with Incomplete Data
Main-branch blindness isn't just an academic measurement problem. It leads to real management failures.
Hidden Leaders Get Overlooked
Sarah spends three months building a foundational library on a feature branch. Zero commits to main during that period. Her manager's dashboard says she went silent. Reality: she rebuilt the entire deployment pipeline. Performance review time comes around, and Sarah's "metrics" show a flat quarter. She gets a mediocre review despite doing some of the most important work on the team.
This happens constantly in organizations that rely on main-branch metrics. The engineers doing the hardest, most foundational work are systematically undervalued because their contributions live on branches that analytics tools can't see.
Bottlenecks Stay Hidden
When you can't see work across all branches, you can't see where it's getting stuck. Maybe your backend team is merging 3× faster than frontend — but you'd never know because you're only measuring the final output. Maybe one engineer is reviewing 70% of all PRs across the organization, a massive bottleneck, and it's invisible because reviews on feature branches don't register.
In Warclick's analysis of newly onboarded teams (Q1 2026), code review concentration is heavily skewed on nearly every team: 2–3 engineers typically handle 70% or more of all reviews, a pattern that's invisible to main-branch-only tools.
All-branch data reveals where work is flowing and where it's blocked. Main-branch data tells you what already shipped, which is useful but insufficient.
Hiring Decisions Are Wrong
If you're using main-branch metrics to decide where to hire, you're working with a distorted picture. A team that appears underproductive might actually be doing enormous amounts of work on feature branches that haven't merged yet. Without complete data, you hire where you think you need people, not where you actually need them.
What's hiding in your feature branches? Warclick captures every commit across every branch, not just main. See your team's real engineering output. Start Your Free 7-Day Trial.
The View from All Branches: What Changes
When you switch from main-branch-only to all-branch measurement, the picture transforms.
How does all-branch visibility change contributor rankings?
Junior engineers often outperform seniors in raw volume — scaffolding, boilerplate, routine refactors generate high commit counts. Seniors do architectural work, critical reviews, and mentorship — lower commit volume but higher impact. Main-branch-only measurement makes juniors invisible and seniors look prolific. All-branch data shows both, and lets you value them appropriately.
On every team Warclick onboards, the ranking of top contributors shifts when all-branch data is revealed. Engineers who were invisible in the main-branch view frequently rank in the top quartile when feature branch work is included.
Specialization Becomes Obvious
With all-branch visibility, team structure reveals itself in the data. You can see that 5 engineers own 80% of infrastructure changes, 8 engineers own 80% of frontend features, and 4 engineers own 80% of backend services. You can use it to plan hiring, identify single points of failure, and make training decisions based on evidence rather than intuition.
Code Review Asymmetry Surfaces
In nearly every team we've onboarded to Warclick, the code review distribution is heavily skewed: 2–3 engineers handle 70% or more of all reviews. Everyone else does a handful. This pattern is invisible in main-branch-only tools because reviews on feature branches don't register.
When you see it, you can act on it. Redistribute review load. Pair senior reviewers with juniors. Prevent the bottleneck that slows your entire PR pipeline.
Why don't most analytics platforms measure all branches?
It's worth understanding why most analytics platforms limit themselves to main branch. It's not laziness. It's engineering complexity that most vendors chose not to solve.
Branch Volume Is Massive
A team of 30 engineers might have 200+ active branches at any given time. Tracking commits across all of them means ingesting and deduplicating orders of magnitude more data than main-branch-only collection. GitHub's own built-in Insights feature measures only the default branch for exactly this reason — it's a product decision driven by infrastructure cost.
Deduplication Is Hard
When a feature branch merges to main, many of those commits already exist in the main branch history. Cherry-picks and rebases create additional copies. Without sophisticated deduplication, all-branch counting inflates numbers and destroys accuracy. Jellyfish, for example, shows the same commit once per branch it appears on, producing inflated counts that require manual analysis to interpret. Getting this right requires per-SHA deduplication with rebase and cherry-pick detection built in from the ground up.
Compare in detail: Warclick vs Jellyfish.
Attribution Gets Complicated
Squash merges, rebases, and force pushes can change commit authorship. Misconfigured git identities mean the same developer might appear as three different people. All-branch analytics needs to handle actor-first attribution — crediting the authenticated GitHub user who pushed, not whatever name is in the git config.
Warclick was built from the ground up to handle all of this: time-chunked ingestion across all branches, idempotent deduplication, squash merge attribution that credits original authors, and cherry-pick detection that prevents inflated counts.
Fair measurement is what makes leaderboards work — here's the psychology behind it.
What to Do Monday Morning
You don't need to take our word for any of this. Run a simple test with your own data:
Step 1: Pick your top 3 engineers — the people you consider your strongest performers.
Step 2: Export all their commits across all branches for the last 3 months. If your current tool can't do this (most can't), use git log --all --author="name" on your repos directly.
Step 3: Compare the all-branch count to what your analytics tool shows (main branch only).
The gap between those two numbers is your "dark work" — the invisible effort your team is putting in that no one can see, measure, or reward. In most teams we've worked with, the gap is 3–5× on a per-engineer basis. Sometimes it's larger.
Step 4: Ask yourself: Is your analytics tool showing you the full picture? Are your performance reviews, hiring decisions, and team structure based on 100% of the data — or 20%?
If the answer is uncomfortable, that's the point.
Ready to fix it? Here's the 30-day playbook for rolling out all-branch analytics.
Stop managing with 20% of the data. Warclick gives you all-branch visibility across every repo, every contributor, and every branch, starting at $4/warrior/month. See the work your team is actually doing. Start Your Free Trial.
Frequently Asked Questions
What is a feature branch in software development?
A feature branch is a temporary Git branch created to develop a specific feature, fix a bug, or run an experiment — separate from the main production codebase. Engineers commit work-in-progress code to feature branches throughout development, then merge them to the primary branch when the work is complete. Most engineering work happens on feature branches, not on main.
Why don't most GitHub analytics tools measure feature branch commits?
The primary reason is engineering complexity. Tracking commits across hundreds of active branches requires ingesting far more data than main-branch-only collection, deduplicating commits that appear on multiple branches, and handling squash merges, rebases, and cherry-picks without inflating counts. Most vendors chose the simpler path — measure only main — because solving all-branch deduplication correctly is a significant engineering investment. GitHub's own built-in Insights tool has the same limitation.
How many more commits are on feature branches compared to main?
Based on Warclick's analysis of engineering teams across the platform (Q1 2026), feature branches contain 3–5× more commits than the main branch during the same time period. For a team that shows 200 commits on main in a given month, all-branch tracking typically reveals 600–1,000 commits total. The ratio varies by team workflow — teams that use squash merging heavily tend to have larger gaps.
How does squash merging affect developer attribution?
Squash merging collapses an entire feature branch's commit history into a single commit on main. When a tech lead squashes and merges a branch that five engineers built together, main-branch-only analytics credits 100% of the work to the tech lead. The original authors receive no attribution for the commits they made on the feature branch. All-branch analytics solves this by tracking the original commits on the feature branch, where authorship is intact.
Can I see feature branch data in GitHub's built-in analytics?
No. GitHub Insights measures activity on the default branch only and does not expose commit-level data across all branches in its analytics views. The GitHub API does allow querying commits across branches programmatically, but building deduplication, attribution, and analytics on top of that requires significant engineering work. Warclick handles this collection, deduplication, and attribution automatically via the GitHub App.
