How to find and export your Azure DevOps data.

Microsoft documents repository size through Git itself: run git count-objects -vH on a clone and read size-pack. The Git Repositories REST API also returns each repository's compressed size in bytes. Add them up and report the total in GB.

At a glance

Report in
GB
Category
Source code
Checked
September 2026
Check your data

Where Azure DevOps shows how much you have.

  1. With a token that has the vso.code scope, call GET https://dev.azure.com/ORG/PROJECT/_apis/git/repositories?api-version=7.1 for each project.
  2. Add up the size field, which is the compressed size of each repository in bytes, and convert the total to GB.
  3. To check a single repository, run git count-objects -vH in a clone and read the size-pack line.

Plan and role. You need permission to read code in each project. To export work items, you must be in the Project Administrators group or have View project-level information set to Allow.

What to report on the Polyshares intake.

Report Azure DevOps in GB. The intake also asks how many years the company has used it and how many seats it has.

Report total repository size in GB. For years in use, use the oldest commit date in your main repositories. For seats, count the users in your organization who work in Repos and Boards.

Work items are a separate data set from code. If you plan to include them, note the work item count from your queries alongside the repository size.

Export the full history.

  1. Run git clone --mirror for each repository to capture every branch, tag and commit.
  2. For work items, open or create a query under Boards > Queries that returns the items and columns you want, select the actions icon, and choose Export to CSV.

Repositories should be no larger than 250 GB, with under 10 GB recommended. Files should be no larger than 100 MB, and pushes are limited to 5 GB. Git LFS objects are stored outside the repository and do not count toward the push limit, so fetch them separately with git lfs fetch --all.

A work item CSV export contains the fields you add as columns in the query, so add every field you want before exporting.

The intake only needs the size, so you do not have to run an export to fill it in. You also do not need to clean or scrub an export. Polyshares handles anonymization before anything moves.

Why Azure DevOps data has value for AI training.

Azure DevOps links commits and pull requests to work items, so a user story, the code that built it and the review around it can be joined. Fields such as state, area path and iteration add a timeline of how the team planned and shipped.

What stays private.

We anonymize identifying details before anything moves. Polyshares does that work, so your team does not have to scrub records first.

Your company keeps ownership of its data. The license is bounded to defined material and a defined use.

Polyshares is the buyer and pays your company directly. There is no fee or commission, and Polyshares reviews the record before it makes any offer.

Common questions about Azure DevOps data.

Where do I see repository size in Azure DevOps?

Microsoft's Git limits page points to git count-objects -vH on a clone. The Repositories REST API also returns a compressed size in bytes for each repository.

Who can export Azure DevOps work items to CSV?

Members of the Project Administrators group, or anyone with the View project-level information permission set to Allow.

Is Git LFS content counted in the Azure Repos size limits?

Git LFS does not count toward the 5 GB push limit because LFS objects are stored separately. Fetch them with git lfs fetch --all to include them in your total.

Source: Git limits - Azure Repos, Repositories - List (Azure DevOps Git REST API), Export, update, and import bulk work items with CSV files. Checked September 2026.

Put your numbers on the intake.

List your systems, their sizes and your headcount in one intake. Polyshares reviews the record and prices it. There is no fee or commission to your company.

Check your data