Find how much you have
Decide which repositories are yours to license before you count anything. Your own products and internal tools are the target. Forks of other people's projects, client work and copied third-party code are not, so leave them out of the total. If code lives in more than one GitHub organization, or in a personal account, count each one separately.
List the repositories. With the GitHub CLI, run gh repo list followed by the organization name, add --source to skip forks and --limit 1000, because the default limit is only 30. The --archived and --no-archived flags split out archived repositories. A developer can instead call GET /orgs/{org}/repos with type=sources and per_page=100 and page until the list ends. Each entry reports archived, created_at and pushed_at. Keep archived repositories in the count if they hold history you would license.
Count commits in each repository. The exact way is a mirror clone, which GitHub's backup guide describes as a backup that includes the repository's revision history. Run git clone --mirror, then git rev-list --count --all inside the clone, which counts the commits reachable from every ref. GitHub's repository statistics endpoints are a poor fit for this. They leave out merge commits, and the contributors endpoint returns zero for additions and deletions once a repository reaches 10,000 commits.
Count pull requests. For an exact figure, page through GET /repos/{owner}/{repo}/pulls with state=all and per_page=100. For a faster estimate, GET /search/issues with a query like repo:ORG/NAME is:pull-request returns a total_count. Search returns at most 1,000 results per query and allows 30 requests a minute for a signed-in user, so mark a figure taken from Search as Estimated.
Find where the history starts. Inside a mirror clone, git log --max-parents=0 --reverse lists the root commits, oldest first. A repository moved to GitHub from another host can carry commits older than its created_at date, so go by the commit dates.
Measure size. Add up the disk size of your mirror clones and note the total in GB in your description. GitHub recommends keeping a repository's .git folder under 10 GB, so a larger one is worth a look for binary files or Git LFS content. GitHub's backup guide says to run git lfs fetch --all to pull LFS objects into a clone.
What to put on your intake
Your intake has five boxes for each system. Here is what goes in each one for GitHub.
- What does it hold?
- First-party source code with its full git history, pull requests with line-level review comments, issues and CI run history. Name the products or services the repositories belong to, and say what you left out, such as forks, vendored code and projects built for clients.
- Data types
- Text for code, commit messages, reviews and issues. Add Structured records if you can supply pull requests, issues and CI runs as data rather than prose.
- How big is it?
- Repositories, from your repository list. Put the commit count, the pull request count and the total clone size in GB in the description so the full picture is visible.
- Verified or estimated
- Verified when the repository count comes from a complete list and the commit counts come from mirror clones. Estimated for pull request counts taken from Search, and for anything you scaled up from a few repositories.
- Records start
- The date of the oldest commit across the repositories in scope, not the date your GitHub organization was created.
Exporting the full history
If a buyer licenses your records, this is how the full history comes out of GitHub.
Nothing is exported until a buyer licenses the code and the scope is agreed: which repositories, which branches, which dates, and whether pull requests, issues and CI history come with the code. The steps below show what to expect.
Git history comes from a mirror clone of each repository in scope. GitHub's backup guide describes git clone --mirror as the way to capture a repository with its revision history, and notes that wikis are stored as Git repositories, so a wiki can be backed up by cloning it too. For repositories that use Git LFS, add git lfs fetch --all.
Pull requests, issues and other metadata can come from an organization migration archive. An organization owner starts one with POST /orgs/{org}/migrations and a list of repositories. Metadata is included unless you set exclude_metadata, which leaves only the Git source. Other flags leave out more, including exclude_git_data, exclude_attachments, exclude_releases and exclude_owner_projects, and a lock_repositories flag that is off by default. Use them to match the licensed scope.
Poll GET /orgs/{org}/migrations/{migration_id} until the state reads exported, then download from GET /orgs/{org}/migrations/{migration_id}/archive. GitHub deletes migration archives automatically after seven days, so download promptly. If you locked repositories for the export, unlock each one afterward with the unlock endpoint.
Open one small archive before you promise a buyer anything. GitHub's page for organization migrations does not list what an archive contains. Its ghe-migrator page, which covers importing these archives into GitHub Enterprise Server, lists issues, issue comments, pull requests, pull request reviews and review comments, commit comments, releases, wikis and file attachments among the data a migration carries. Its backup guide adds that migration archives do not include all repository data, and names Git LFS objects, discussions and packages as left out.
Check for secrets before anything moves. GitHub says secret scanning covers the whole Git history on all branches, plus issues, pull requests and discussions, but for private organization repositories it needs GitHub Secret Protection. 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
- Only organization owners can use the Migrations API. Anyone who can clone a repository can count its commits, but an organization export needs an owner.
- GitHub's guide to exporting from GitHub.com says the final archive must be less than 20 GB. A large organization may need several migrations, each with a subset of the repositories.
- GitHub says migration archives are designed for moving data between GitHub products, and that there is no supported, documented way to restore one on GitHub. Treat the archive as a delivery format, not as your backup.
- Actions artifacts and logs are deleted after 90 days by default. Private repositories can set a period from 1 to 400 days and public ones 1 to 90, and a changed setting applies only to new objects. GitHub says that starting October 1, 2026 the same setting also applies to checks, workflow runs and commit statuses, which were previously kept for 400 days or more. Ask an owner what the setting is and whether it has ever been changed, because older CI history may already be gone.
- A deleted repository can be restored within 90 days, by an organization owner for organization repositories. One that belonged to a fork network that is not empty has to be restored by GitHub Support, which is only available on a paid plan. Restoring does not bring back team permissions. If you deleted something by mistake, restore it before you count.
- GitHub's API limits shape how long a pull takes. A signed-in user gets 5,000 requests an hour, and GITHUB_TOKEN inside Actions gets 1,000 an hour per repository. Secondary limits also apply, including no more than 100 concurrent requests. A developer should pace requests by the x-ratelimit headers on each response and back off when they run low, and GitHub warns against logic that depends on an exact remaining count.
- Most REST list endpoints return at most 100 items per page, and Search stops at 1,000 results for a query, so large counts take many requests or a split by date or repository.
- GitHub recommends keeping a repository under 10 GB and enforces a 100 MB limit on a single object. A repository that runs past those figures is probably carrying binaries or LFS content, so size that part separately.
- Repository statistics are cached against the default branch and can answer with a 202 while GitHub compiles them. Do not use them for your intake figure.
- Rewriting history does not undo a leak. GitHub says rewritten commits may still be reachable through other people's clones, forks and pull request references, and that revoking or rotating the secret comes first. You do not need to clean your history before you size it.
This guide isn't legal advice. Check your contracts, and any recording-consent rules that apply, with your own lawyer.
Why buyers value it
A private repository holds something public code cannot: one real product's history as it was actually built. Each commit is a change plus the message explaining it. Each pull request pairs a proposed diff with reviewers' line-by-line comments and the revisions that followed. When an issue links to the pull request that closed it, you get a problem paired with its solution.
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. Years of refactors, reverted mistakes and migrations in a codebase that was never public are 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, .env files 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
Sources
Vendor documentation, checked . Screens and plans change, so if a step looks different in your account, check with GitHub.
- GitHub Docs: REST API endpoints for organization migrations (opens in a new tab)
- GitHub Docs: Backing up a repository (opens in a new tab)
- GitHub Docs: Exporting migration data from GitHub.com (opens in a new tab)
- GitHub Docs: About ghe-migrator (opens in a new tab)
- GitHub Docs: REST API endpoints for repositories (opens in a new tab)
- GitHub Docs: REST API endpoints for pull requests (opens in a new tab)
- GitHub Docs: REST API endpoints for repository statistics (opens in a new tab)
- GitHub Docs: REST API endpoints for search (opens in a new tab)
- GitHub Docs: Using pagination in the REST API (opens in a new tab)
- GitHub Docs: Rate limits for the REST API (opens in a new tab)
- GitHub Docs: Repository limits (opens in a new tab)
- GitHub Docs: Configuring the retention period for checks, workflow runs, commit statuses, artifacts and logs (opens in a new tab)
- GitHub Docs: Restoring a deleted repository (opens in a new tab)
- GitHub Docs: About secret scanning (opens in a new tab)
- GitHub Docs: Removing sensitive data from a repository (opens in a new tab)
- GitHub Docs: GitHub Terms of Service (opens in a new tab)
- GitHub CLI manual: gh repo list (opens in a new tab)
- Git documentation: git-rev-list (opens in a new tab)
- Git documentation: git-log (opens in a new tab)