Home > Back-end >  How to push Unity project (files together over 1GB) to the GitHub without splitting it?
How to push Unity project (files together over 1GB) to the GitHub without splitting it?

Time:12-03

I am trying to push my Unity project to GitHub and this error appears:

batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.

I want to have my entire project on one repo without splitting it. Is there any way to do it?

There is this topic but I'm not really sure what that answers say. If they are correct can someone simplify them to me?

Also here someone said that once a month you get 1GB on git lfs but on witch day of the month this happen?

CodePudding user response:

If you need to distribute large files within your repository, you can create releases on GitHub.com. Releases allow you to package software, release notes, and links to binary files, for other people to use. see the GitHub documentation. There is no limit to the total size of the binary files in the release or the bandwidth used to deliver them. However, each individual file must be smaller than 2 GB.

Instead, if you've got really large binary files, besides git-lfs which has a lightweight pointer to your file you might wanna consider git-annex to store the data outside of the repository. I think that git-lfs refreshes your bandwidth limit one month after you reached the limit.

That being said, In my opinion, the best option would be to store on GitHub only the source code of your project and add all large assets files, typical of a game (meshes, textures, audio files, etc.) on a separate database (Amazon S3, Google Cloud, etc.). Only push their relative .meta files and add a pre-processing script that downloads and injects your dependencies inside your project before opening it in the editor. This could be a magefile or more simply a shell/bash script.

In this way, you can organize (multiple) archived packages that you can update manually and use your own versioning method (renaming the archives with the date they were created, the dependencies versions, etc.).

This gives you more granular control over the files you will inject as git cannot generate meaningful diffs, or merge binary files in any way that could make sense. So all merges, rebases, or cherrypicks involving a change to a binary file will involve you making a manual conflict resolution on that binary file and you would not break GitHub guidelines on this. Quoting:

We recommend repositories remain small, ideally less than 1 GB, and less than 5 GB is strongly recommended. Smaller repositories are faster to clone and easier to work with and maintain. If your repository excessively impacts our infrastructure, you might receive an email from GitHub Support asking you to take corrective action.

  • Related