Skip to content

Code repositories

How to find and size your GitLab data.

Find how many projects, commits and merge requests GitLab holds, and how a full-history export works with mirror clones, file exports and the API.

Get your data pricedAll guides

Find how much you have

  1. Decide which projects are yours to license and which GitLab you are on, because limits differ between GitLab.com and Self-Managed. Your own products and internal tools are the target. Forks of other people's projects, client work and copied third-party code are not. If code lives in several top-level groups, count each separately.

  2. List the projects. A developer calls GET /projects with membership=true, statistics=true and per_page=100, and pages until the list ends, because the default page size is 20. GitLab shows statistics only to users with the Reporter role or higher. Leave out the archived attribute so archived and active projects both come back, then run it again with archived=true to see which projects are archived.

  3. Read the totals. The X-Total response header gives the number of projects, but GitLab leaves it out when a query matches more than 10,000 records. For each project, the statistics object reports commit_count and sizes in bytes, including repository_size, lfs_objects_size and job_artifacts_size.

  4. For a commit count that does not rely on GitLab's statistics, take a mirror clone with git clone --mirror and run git rev-list --count --all inside it, which counts the commits reachable from every ref. Say in your description which method you used.

  5. Count merge requests and issues. GET /projects/:id/merge_requests with state=all and per_page=1 returns the total in the X-Total header. The merge request list that spans projects returns only the ones you created unless you pass scope=all. For issues, GET /projects/:id/issues_statistics returns counts of all, opened and closed issues. On Self-Managed or Dedicated, an administrator can call GET /application/statistics for instance-wide counts. GitLab says values under 10,000 are exact, and larger ones can be approximate.

  6. Find where the history starts. In a mirror clone, git log --max-parents=0 --reverse lists the root commits, oldest first. A project imported from another host may carry commits older than the project itself, so go by the commit dates.

  7. Check size in the project under Settings, then Usage quotas, then Storage, which a Maintainer or Owner can open. GitLab updates it about every 90 minutes. Only the repository and LFS count toward the storage limit. Add up the repository sizes for a GB figure to note in your description.

What to put on your intake

Your intake has five boxes for each system. Here is what goes in each one for GitLab.

What does it hold?
First-party source code with its full git history, merge requests with review comments, issues, wikis and CI pipeline records. Name the products the projects belong to, and say what you left out, such as forks, vendored code and client projects.
Data types
Text for code, commit messages, reviews and issues. Add Structured records if you can supply merge requests, issues and pipeline results as data rather than prose.
How big is it?
Repositories, from your project list. Put the commit count, the merge request count and the total repository size in GB in the description so the full picture is visible.
Verified or estimated
Verified when the project count comes from a complete list and the commit counts from statistics or mirror clones you ran yourself. Estimated for anything you scaled up from a few projects, or counts that GitLab marks as approximate.
Records start
The date of the oldest commit across the projects in scope, not the date your GitLab group was created.

Exporting the full history

If a buyer licenses your records, this is how the full history comes out of GitLab.

  1. Nothing is exported until a buyer licenses the code and the scope is agreed: which projects, which branches, which dates, and whether merge requests, issues and pipeline records come with the code. The steps below show what to expect.

  2. Git history comes from a mirror clone of each project in scope, using git clone --mirror, which maps every ref and not only the branches. GitLab's project file export also includes the project and wiki repositories if you would rather take everything in one file.

  3. For issues, merge requests and comments, a Maintainer or Owner opens the project's Settings, expands Advanced under General, and selects Export project. GitLab emails a link when it is ready, and the file can also be downloaded from the settings page. It carries issues with comments, merge requests with comments, reviewers and approvers, labels, milestones, snippets, releases, boards and commit comments.

  4. A developer can run the same export through the API. POST /projects/:id/export returns 202 Accepted. Poll GET /projects/:id/export until export_status reads finished, then fetch GET /projects/:id/export/download. The excluded_relations option leaves out relations the license does not cover, though the repository itself cannot be excluded.

  5. Plan for GitLab's limits. By default an instance exports 6 projects a minute and allows 1 download per project a minute, and a worker deletes export files every 24 hours, so download right away. GitLab.com lists a maximum export size of 40 GiB.

  6. Check for secrets before anything moves. GitLab's pipeline secret detection scans the current state of the repository by default. To scan every commit and branch, run a historic scan once by creating a pipeline with the CI/CD variable SECRET_DETECTION_HISTORIC_SCAN set to true. Rotate any credential it finds. Under the license, credentials and personal identifiers are removed or left out of what the buyer receives.

We only ask for an export after you sign a license and agree the scope. Sizing your data for the intake never needs one.

Limits to know

  • GitLab says not to use project export files as a backup of your data. Treat the file as a delivery format.
  • In a file export, only the latest diff and the latest pipeline of each merge request stay visible. Links between issues and their linked items, and links to related merge requests, are not exported. A developer may need the API to rebuild issue-to-fix pairs.
  • CI/CD variables, job traces and artifacts, webhooks, deploy keys, and package and container registry images are not in a project file export. Job logs and artifacts are not migrated by direct transfer either. Artifacts expire on a job's expire_in setting or the instance default, which GitLab.com lists as 30 days unless otherwise specified. GitLab says deleting a job's log and artifacts cannot be reverted, so older pipeline output may already be gone.
  • Direct transfer, which GitLab calls the recommended migration method, copies groups from one GitLab to another. It matters only if a buyer runs its own GitLab, and on Self-Managed and Dedicated an administrator has to turn it on first.
  • GitLab.com lists a repository size limit of 10 GB including LFS, a maximum import size of 5 GiB and a maximum export size of 40 GiB. On Self-Managed, administrators set the maximum import size, and the default is unlimited.
  • GitLab.com permanently deletes groups and projects 30 days after deletion, under its delayed deletion setting. Check recently deleted projects before you count.
  • Pagination shapes how long a pull takes. Pages default to 20 items and cap at 100, offset pagination has a maximum offset, and GitLab recommends keyset pagination for large collections where it is available.
  • GitLab.com currently limits authenticated API traffic to 2,000 requests a minute per user, with other limits per IP address and per project. Limits by plan, per user and per top-level group, are proposed but not yet in effect. A throttled request gets HTTP 429. GitLab says to wait for the Retry-After duration, back off if throttling continues, and watch RateLimit-Remaining to slow down early.
  • Rewriting history is not required and is not a free fix. GitLab says removing blobs and redacting text both drop commit signatures, can leave open merge requests needing a manual rebase, can break pipelines that reference old commit SHAs, and are irreversible.

This guide isn't legal advice. Check your contracts, and any recording-consent rules that apply, with your own lawyer.

Why buyers value it

GitLab often keeps the whole delivery chain in one place: the code, the merge requests with their review threads, the issues, and the pipelines that ran against each change. That makes it easy to line up a problem, the change that fixed it, and the tests that checked it.

Buyers building coding and code-review models want long, continuous histories where the tests run, because tests let them score a model's change automatically. A project that has gone through years of refactors, reverted changes and migrations, and was never public, is difficult to find anywhere else.

What stays private

Buyers receive de-identified operating records. Under the license, the de-identification step before delivery removes or excludes:

  • People: author, committer, reviewer and commenter names and email addresses, removed or replaced the way the license specifies.
  • Credentials and infrastructure: keys, tokens, passwords, CI/CD variables and internal hostnames, wherever they appear in history. Anything found is yours to rotate.
  • Code you do not own: vendored dependencies, copied snippets, and code written for clients or by contractors without a written assignment.
  • Security-sensitive work: vulnerability reports, penetration test results and anything about unpatched issues.
  • Customer data: database dumps, logs and test fixtures built from real customer records.

Common questions

No. GitLab says not to use project export files as a backup. The file carries the repositories, issues, merge requests with comments and more, but it leaves out CI/CD variables, job logs and artifacts, webhooks and registry images, and it keeps only the latest merge request diff. It is a way to hand over a defined scope, not a copy of your instance.

The merge request list that spans projects returns only the ones you created unless you pass scope=all. Counting per project with state=all avoids that. Also check whether the X-Total header is missing, which GitLab does when a query matches more than 10,000 records, and count pages instead.

Your administrators control the limits, including the maximum import size, and can use admin-only endpoints such as the application statistics API for instance-wide counts. The project export steps are the same, but the GitLab.com figures in this guide do not apply, so ask your admin for your own instance's settings.

Sources

Vendor documentation, checked . Screens and plans change, so if a step looks different in your account, check with GitLab.

Related guides for systems that often sit alongside it.

Code repositories

GitHub

Find how many repositories, commits and pull requests GitHub holds, and how a full-history export works with mirror clones and the organization Migrations API.

Issue tracking and projects

Jira

Find how many work items Jira Cloud holds, and how a full-history export works through Backup manager, CSV batches and the REST API.