The biggest limitation of Git, compared to some older centralized version control systems, has been the maximum size of the repositories.

The general recommendation is to not have Git repositories larger than 1GB to preserve performance. Although GitLab has no limit (some repositories in GitLab are over 50GB!), we subscribe to the advice to keep repositories as small as you can.

Not being able to version control large binaries is a big problem for many larger organizations. Videos, photos, audio, compiled binaries and many other types of files are too large. As a workaround, people keep artwork-in-progress in a Dropbox folder and only check in the final result. This results in using outdated files, not having a complete history and increases the risk of losing work.

This problem is solved in GitLab Enterprise Edition by integrating the git-annex application.

git-annex allows managing large binaries with Git without checking the contents into Git. You check-in only a symlink that contains the SHA-1 of the large binary. If you need the large binary, you can sync it from the GitLab server over rsync, a very fast file copying tool.

Your files can be found in the master branch, but you'll notice that there are more branches created by the annex sync command.

Git Annex will also create a new directory at .git/annex/ and will record the tracked files in the .git/config file. The files you assign to be tracked with git-annex will not affect the existing .git/config records. The files are turned into symbolic links that point to data in .git/annex/objects/.

By using git-annex without GitLab, anyone that can access the server can also access the files of all projects, but GitLab Annex ensures that you can only access files of projects you have access to (developer, master, or owner role).

Internally GitLab uses GitLab Shell to handle SSH access and this was a great integration point for git-annex. There is a setting in gitlab-shell so you can disable GitLab Annex support if you want to.