How do you export GitLab repositories and merge requests for an AI data license?
A GitLab instance holds code, the reviews written about it and the issues that explain why it changed. A project export bundles much of this in one archive, and the API can pull the rest. Hosted and self-managed installs behave differently in places, so the first step is to find out which one the company runs.
What a GitLab instance usually holds
| Repositories and history | Every commit with its message and author. The history shows how a codebase grew, which is hard to see in a snapshot. |
| Merge requests with reviews | The proposed change, reviewer comments, approvals and the reply. GitLab's documentation lists comments, reviewers and approvers as part of a project export. |
| Issues and comments | Bug reports and feature requests with the discussion that followed. Labels and milestones show how work was sorted. |
| Wikis | Each wiki is a separate Git repository with its own history, holding internal documentation. |
| Pipelines and snippets | Archived CI/CD pipelines and code snippets are listed in the export. Job logs are another matter and are covered below. |
How data leaves GitLab, route by route
| Tool | What an export gives you | What is missing or needs an admin |
|---|---|---|
| Project export file from the settings page | One archive per project: repositories, wiki, issues with comments, merge requests with comments, reviewers and approvers, labels, milestones, releases and boards. | GitLab lists CI/CD variables, job traces and artifacts, webhooks, integrations and package registries as not included. GitLab also says an export file should not be used as a backup. The role needed is Maintainer or Owner. |
| Project export through the API | The same archive, started with a request, checked for status and then downloaded. It can leave chosen parts out, such as issues or merge requests. | Administrators can set an export size cap. The default in the documentation is unlimited. |
| Group migration by direct transfer | A copy of a whole group with its projects into another GitLab instance, if that is the goal. | It copies into GitLab rather than producing a file to hand over. On self-managed installs an administrator must turn it on. |
| REST API lists for issues and merge requests | Merge requests and issues at project or group level, filtered by date, with approvals through their own endpoints. | Page size is capped, and rate limits apply. Rows come as data fields and need work to read as threads. |
| Cloning the repository and the wiki | Full Git history for code and for each wiki, using ordinary Git. | Only what Git stores. Reviews and issues are not in a clone. |
Tool names belong to their owners and are used only to say where records usually live. Export features change by plan and version, so check the current rules for your account.
Hosted and self-managed, as documented
GitLab documents a fixed maximum import size on GitLab.com, while administrators of self-managed installs set their own. Rate limits for exports are given per user, and the page we read listed six project exports a minute and one download per project a minute. An export file is kept only briefly, so download it when it finishes.
Contributor links behave differently when data moves between instances. For a license this matters less than it does for a migration, but it explains why a file that looks complete on one install can show different authors on another. Check the current rules for the version in use, since GitLab also requires matching or newer versions for imports.
Counting projects, merge requests and issues
Report projects, merge requests and issues, with the first and last dates. A merge request count comes from the list in the project or group, and a figure read from the screen is an estimate until it is matched against an export. GitLab notes that responses with more than 10,000 records leave out the total-count headers, so large instances need their own counting step.
Say how many merge requests carry a human review comment, since that is the layer most useful to a buyer. Note also how many projects are archived and how many repositories hold code written by outside contractors.
Cleaning and ownership before anything leaves
Commit authors and reviewers appear by name and email. Those are replaced with de-identified codes, and secrets that were once committed into history must be searched for, because deleting them in a later commit does not remove them from earlier ones. Open source code mixed into a repository keeps its own license, and customer code written under a contract may belong to the customer.
Group-level ownership decisions belong to the company, so check employment and contractor agreements. This is general information, not legal advice, so involve counsel before a set is prepared.
What a GitLab set leaves out
| Secrets, tokens and keys | Found by scanning the full history and removed, or the repository is left out of the license. |
| Developer names and emails | Replaced with de-identified codes that keep one person's work together. |
| Customer-owned and third-party code | Repositories written for a client or copied from outside projects are not licensed. |
| Private issues | Confidential issues and security reports are left out by default. |
A sample drawn from one self-hosted server
A logistics software company runs GitLab on its own servers. An administrator lists the projects, and a maintainer exports the five with the longest review history through the API. The team counts merge requests with review comments, scans history for committed secrets and removes one repository written for a client. Developer names become codes, and a small sample of cleaned merge requests goes to the owner, who decides whether the set moves ahead.
Questions owners ask about this
Is the project export file a backup?
GitLab's own page says not to use it as one. Treat it as a snapshot of selected records and keep your normal backups separate.
Do we get CI job logs in the export?
GitLab lists job traces and artifacts as not included. Archived pipelines are listed, so check what you actually receive before counting them.
We run self-managed GitLab. Does anything change?
Yes. Administrators control size caps and some features, and an administrator may be needed for certain steps. Ask whoever runs the server which settings apply.
Can a normal developer run the export?
The documentation we read says Maintainer or Owner on the project. Group-wide work usually falls to a group owner or administrator.
Didn't find your question? Ask us directly.
Sources
The vendor's own pages this guide draws on. Some help centers did not open for us, and where a step rests on a summary and not the page itself, the guide says so. Menus and limits change by plan and version, so check the current pages for your account.
Keep reading
Related kinds of records
- Project and task history: Jira, Asana, Linear, Monday, Trello, ClickUp and Airtable comments and status changes, not task titles.
- SOPs and knowledge bases: Procedures with their edit history and comments; published help articles add nothing.
- Code and pull request history: The commit, the review and the failed fix before the working one, with secrets and borrowed code removed.
- GitHub repository export: How to take code, pull requests and review comments out of GitHub, and the keys to remove first.