GitHub Repository Size Limit: The Numbers That Block You

Here's the short version, as of Nov 2026, taken from GitHub's own Repository limits page in GitHub Docs. There isn't one size limit. There's a recommended ceiling for the whole repository, two hard blocks that stop a push in its tracks, and a long tail of softer limits that don't block anything but make your repo slow and your pull requests hard to read.

The thing most people miss: GitHub's recommended maximum for a single object is 1MB. The 100 MB figure everyone quotes is the point where GitHub refuses the file outright. So the gap between what GitHub would like and what it'll tolerate is a hundred times. If your history is full of files in that gap, nothing breaks today, but you're the repo that gets slow first.

The cheat sheet: recommended versus enforced

I've split each figure by whether GitHub enforces it or only recommends it, because that's the question that matters when a push fails at the worst moment.

Limit	Figure	Type	What it means
On-disk size	10 GB	Recommended	Size of the .git folder, the compressed form of the repository
Push size	2 GB	Enforced	A single push larger than this is rejected
Single object (file)	1MB recommended, 100 MB enforced	Both	Files over 100 MB are blocked; GitHub points you to Git LFS
Git read operations	15 per second per repository	Recommended	Fetches and clones, often from CI
Push rate	6 pushes per minute per repository	Recommended	Bots and automation hit this first
File previews	Generally less than 2 MB	Behaviour	Bigger or complex files fall back to plain text or don't display
Pull request diff	20,000 lines or 1 MB of raw diff	Display limit	No total diff in a pull request loads past this
Files in one diff	300	Display limit	Anything past the limit isn't shown
Renderable files in one diff	25	Display limit	Images, PDFs and GeoJSON files
Commits listed in compare and PR views	250	Display limit	A note says more commits exist
Rebase and merge	100 commits	Enforced	Over that, merge, squash or split the pull request
Repositories per account or organization	100,000 (banner at 50,000)	Enforced	Admins also get email warnings

Which numbers stop you and which just slow you down

GitHub's wording is careful here. Going past a recommended maximum increases the risk of degraded repository health, which it describes as slow response times for basic Git operations and UI latency. It also adds a note that following the guidelines doesn't guarantee supportability, because other factors can still cause unexpected behaviour. In plain English: the recommended figures are where things start to hurt, not where they stop.

The numbers that stop you cold are the push size of 2 GB, the single file block at 100 MB, the 100-commit cap on Rebase and merge, and the account ceiling of 100,000 repositories. If you're seeing a rejected push, it's almost always one of the first two. If a pull request won't rebase, it's the third, and GitHub's answer is to create a merge commit, squash and merge, or split the commits across more than one pull request.

The diff limits are a different animal. They don't block a merge, they hide content. A pull request that runs past 20,000 lines or 1 MB of raw diff data won't load the rest, and only 25 renderable files show in a single diff. That's a review problem, not a storage problem, and it's the one that quietly lets bad code through because nobody could see it.

When are you at risk? A quick checklist

Run down this list. Each line maps to something GitHub's limits page calls out, so if you tick two or more, it's time to act before the repo gets sluggish.

• You commit binary files such as builds, media or design exports. GitHub recommends Git Large File Storage (Git LFS) for binary files.
• You commit programmatically generated files. GitHub suggests storing those outside Git, such as in object storage.
• Your .git folder is heading toward 10 GB. Large repositories slow down fetches and increase clone times for developers and CI.
• Your history holds lots of files bigger than 1MB, even if none are near the 100 MB block.
• Your CI clones the full repository on every job. GitHub's recommended maximum is 15 read operations per second per repository, and it notes shallow clones put less burden on the server than full clones.
• Bots or scripts push more than 6 times a minute.
• You keep huge flat directories, very deep folder trees or a mountain of stale branches. The docs give recommended ceilings for directory width, directory depth and number of branches too.
• Your pull requests regularly run into the hundreds of files. Past 300 files in a diff, reviewers simply can't see the rest.

What to do once you're over

Start with the files. Move binaries into Git LFS, and move generated output out of the repo entirely. If your CI is the heavy reader, switch it to shallow clones or put a repository cache server in front of it, which is exactly what GitHub suggests. If you work with AI coding assistants that commit generated files on your behalf, check what they're adding, because that's an easy way to bloat history without noticing.

For previews, remember every file is still available raw. GitHub serves raw files through raw.githubusercontent.com, and the Raw button on any file gives you that address. So a big Markdown file that won't render isn't lost, it's just not pretty. And if you're building a portfolio to land remote developer roles, a lean, well-structured repo says more about you than a bloated one ever will.

My verdict: treat 1MB per file and 10 GB per repo as your working limits, and treat 100 MB and 2 GB as the cliff edge. Teams that plan around the cliff edge spend their time fighting slow clones. Teams that plan around the recommendations rarely think about size at all.

What GitHub's limits page leaves out

Two things people ask about aren't on the page. It doesn't give exact Git LFS pricing, so check that on GitHub's billing pages before you move a lot of data into LFS. And it doesn't state a per-repository file count limit; the closest it gets is the recommended directory width and depth figures.

Quick answers

What's the maximum repository size on GitHub?

GitHub recommends keeping the on-disk size, the .git folder, under 10 GB. It's a recommendation rather than a hard block, but going past it raises the risk of slow Git operations.

What's the largest file I can push to GitHub?

GitHub enforces a block at 100 MB per single object, and its recommended maximum is 1MB. For larger files it recommends Git LFS.

Is there a limit on push size?

Yes. GitHub enforces a push size limit of 2GB, so split very large pushes into smaller ones.

Why won't my pull request rebase and merge?

Rebase and merge is limited to 100 commits. Over that, create a merge commit, squash and merge, or split the commits into several pull requests.