Managing repository size of a remote git repo

504 Views Asked by At

I am experiencing this issue where my repository is reaching the 2GB size limit in Bitbucket. I have several branches in the repo at a given time, each about ~260MB (due to some images I keep in the repo to make it easier to share with team). Given this file size, I should be well below the 2GB limit for anything under 8 branches. However, I am often given warnings and sometimes locked out due to hitting the limit and have to delete some branches.

I noticed that the hidden .git directory in the root or the project is quite large (~3GB). How is this directory handled in the remote? Obviously, it's not uploaded. Is it recreated in the remote? Could that be why the repo size in the remote is so large?

I tried running git gc which reduced the size of the .git directory to about 2.3GB but this has not resolved the issue since (1) it's not enough and (2) it's local to my machine. Is there a way to git gc in the remote?

1

There are 1 best solutions below

0
sbat On
  • To answer your specific last question, it looks like you can ask Bitbucket Support to perform GC for you: https://confluence.atlassian.com/bitbucket/reduce-repository-size-321848262.html However, it probably makes sense to only do that when you've resolved the underlying issues, cleaned-up the repo and just need this one final step.

  • Number of branches per se has nothing to do with the repository size. Branches are just pointers in Git, each branch overhead is exactly 41 bytes. https://git-scm.com/book/en/v1/Git-Branching-What-a-Branch-Is What matters is how many revisions of the large binaries you have in your history.

  • From practical standpoint, it seems you will have to remove large binary files from the repository and/or from the repository history. There's a good overview of your options here: https://help.github.com/en/articles/removing-sensitive-data-from-a-repository. Of course it is important to backup the repo entirely first, and carefully review all the implications of the history rewrite. Once this is done, you can reevaluate your options (git-lfs, another git hosting, do not keep large binaries in the repo).