How to connect your Git repositories and see throughput data in a day

Connecting your repositories takes an afternoon, and a first scored read of your history lands the same day. The slower part is the baseline: deciding which repositories count, which historical window predates your first coding assistant, and which committers in your history are service accounts. Explore is free for 14 days and analyzes up to 1,000 pull requests, which is enough to determine whether your data is clean.

What the missing measurement costs before anyone connects anything

Picture the renewal decision. It lands on a Thursday, four months into the team’s use of the assistant. There’s a spend figure from finance, a developer survey reporting that people feel faster, and no way to compare what the team shipped in the two quarters before the tools arrived against what they shipped in the quarters after.

The renewal goes through. There’s nothing else to do with information like that.

The data needed to answer it had been sitting in the Git history for three years. Nobody had scored it because scoring a merged change by its worth requires a pipeline, and building that pipeline competes with shipping the product.

That’s the gap a connection closes on day one. What it doesn’t close on day one is the baseline, and the difference between those two things is the whole point of this post.

What the first day actually covers

Navigara reads from GitHub, GitLab, Jira, and Linear. Sign-up is available at app.navigara.com/onboarding, and the Explore tier is free for 14 days, with up to 1,000 pull requests analyzed.

Here is what finishes within a day, assuming someone with admin rights on the Git organization is available when you start:

• The repository connection itself, plus the tracker connection if you want work items attached to changes.
• A first pass over the history of whatever repositories you brought into scope.
• A first-team-level read, where the data-quality problems become visible.

Here is what does not finish inside a day:

• A baseline you’d defend in a budget meeting.
• Agreement inside your own org about which repositories represent the team’s work.
• A committer list with bots, vendors, and departed contractors resolved.

Those three are decisions about your own organization, and they need a human who knows the history of your repository sprawl.

Which repositories belong in scope

Start narrower than feels right. Three to five repositories that carry the work your team is judged on beats twenty that include a Terraform module last touched in 2023.

Two failure modes to watch for.

Scope that grows between the baseline and the current period. A baseline drawn from four repositories, compared against nine, produces a delta that is mostly the five new repositories. This is the single most common way an internal measurement attempt produces a number that falls apart when faced with a single question.

Repositories with a different work character. An infrastructure-as-code repository and a product service repository accumulate changes at different rates for reasons unrelated to assistant adoption. Measure them, keep them separate, and don’t average them into one figure you then have to explain.

Write the repository list down before the first pass runs. The list is part of the method, and a method you can hand to a skeptical CFO is worth more than a dashboard you can’t reconstruct.

How to choose the historical window for the pre-AI baseline

Pick a window that ended before the first assistant landed in the workflow rather than before the first license was purchased. Those dates are often a quarter apart because procurement and adoption follow different calendars.

For most US teams, the pre-assistant period falls between late 2022 and mid 2023. Two full quarters is enough. One quarter carries too much noise from a single large release.

Then exclude windows that are measuring something other than delivery:

• A quarter in which the team changed size by more than 20%. That baseline is measuring the reorg.
• A monolith-to-services migration. The volume of change in a migration quarter is unrelated to feature throughput.
• A quarter containing a freeze, an acquisition, or a compliance push that consumed most of the team.

If every candidate window has one of those problems, say so in the report. A baseline with a stated flaw beats a clean-looking number that quietly contains a reorg.

What to do about bot and service accounts

Your commit history has non-humans in it. Dependabot or Renovate, release automation, a migration script somebody ran once under their own credentials, and at least one account whose name nobody in the room recognizes.

Left in, they inflate the historical window and flatten the comparison. Dependency bumps arrive at a steady machine rate, diluting any real change in what the team shipped.

Three practical steps:

Get the committer list before you get the number. The first pass gives you every identity that appears in the window. Read it with two people who have been at the company the longest.

Decide on the ambiguous ones explicitly. Contractors, an agency that shipped one integration, an intern cohort. There is no correct answer, only a consistent one, and consistency across both windows is what matters.

Re-check identities as well as names. The same engineer often appears under three email addresses, and a laptop change mid-window can split one person into two committers.

If you want to see what your own committer list and historical window look like before committing to a rollout, connect a repository, and the first pass will score the history you already have.

How monorepos change the setup

A monorepo makes repository scope useless, as the whole company lives in one repository. The unit becomes the path.

Decide which directories map to which team, and decide it with the teams present. Path ownership drifts, and a CODEOWNERS file written eighteen months ago records what ownership looked like then, not now. Merge policy matters more here than anywhere else. A team that squashes a twelve-commit branch into one commit and a team that merges all twelve produce very different commit counts for identical work. Navigara’s own Q2 2026 study names this as an uncontrolled variable in its sample: “Monorepo versus polyrepo workflow, squash-merge policy, and public-versus-private code mix are not controlled.” If the study can’t control for it across six organizations, your internal comparison across two teams can’t either. Keep monorepo paths and standalone repositories reported separately.

And if your merge policy changed inside the window, the change is in your data. Find the date, note it, and treat the segments on either side as different series.

Why the baseline takes longer than the connection

Usually two to four weeks, against an afternoon for the connection.

That time goes into resolving bot accounts, settling the repository scope with people who disagree about it, finding the period when the CI provider changed, and the commit metadata changed with it, and discovering the repository that three engineers forgot existed.

Your first number will be wrong. The first pass surfaces the problems in the data rather than the answer, which is the useful thing it does. Fix those, rerun, and take the second number into the meeting.

Anyone promising a defensible pre-AI baseline on day one is promising something no measurement of your history can give, because the flaws in that history are yours and they have to be found before they can be stated.

Talk to us if you’d rather have the first pass run against your repositories than build the pipeline internally.