GitHub doesn’t have any set disk quotas. We try to provide abundant storage for all Git repositories, within reason. Keeping repositories small ensures that our servers are fast and downloads are quick for our users.
Rule of thumb: 1GB per repository, 100MB per file
For best performance, we recommend repositories be kept under 1GB each. This limit is easy to stay within if large files (typically, binaries) are kept out of the repository. If your repository exceeds 1GB, you might receive a polite email from support requesting that you reduce the size of the repository to bring it back down under 1GB.
In addition, we place a strict limit of files exceeding 100 MB in size. For more information on why this is, see our article on working with large files.
Though it sounds like Git would make an amazing backup tool, Git really doesn’t work out well for backups over the long term. Many solutions that are specifically designed for performing backups are even less expensive than GitHub’s Micro plan.
Some services worth checking out include Arq, Backblaze, Carbonite, Mozy and CrashPlan.
Large SQL files do not play well with version control systems such as Git. If you are looking to provide your developers with the most recent production dataset, we recommend using Dropbox for sharing files like these among your developers.
If you are looking to backup your production servers, see the Backups section above.
Another thing that causes Git repositories to become large and bloated are external dependencies. It’s best to leave these files out of the repository and use a package manager instead. Most popular languages come with package managers that can do this for you. Bundler, Node’s Package Manager and Maven are shining examples. They each support using a git repository directly as well, so you don’t need pre-packaged sources.
Packaged release versions
Unfortunately, git isn’t very good at distributing compiled code and pre-packaged releases. Check out this guide for alternative distribution options.