1

I would like to know which factors contribute to the size of a git repo, Except the data of course.

Does having a long history means a big repo? Does having many branches have some affect on it?

Also how do you guys handle your commits? I read that each commit should have at least one logical unit of change added to it. I know that commits can be squashed by rebasing before pushing. (Never rebase published of course).

So i don't know if i should squash them or not. Because i don't know if it makes any change to the size or not.

Thanks

James Moore
  • 8,636
  • 5
  • 71
  • 90
Mukul
  • 141
  • 1
  • 11
  • 1
    For git workflows: https://www.atlassian.com/git/tutorials/comparing-workflows/ Branches are merely pointers to commits, so they don't take up too much space. Commits with changes to many files do take up more space, and a longer history often correlates to more commits, so that often correlates to a bigger repo. – Luke Jul 19 '15 at 13:10

1 Answers1

0

A repo itself will see its size vary mainly because of the nature of the data put in it: binary data will be less efficiently stored than non-binary data, and is generally bigger anyway.

A repo in use (locally clone) can see its size vary depending on the last gc and repack: See git gc --aggressive vs git repack. Packfiles are where deltification is done.

As for the commits, read "Utter Disregard for Git Commit History".

These are two extremes of viewing what the core unit of change is for the respective project.

  • From Git’s perspective — likely because of the ease of use inside a mailing list approach — a single atomic commit makes most sense.
  • From GitHub’s perspective, individual commits become less valuable because the atomic unit is the pull request

In both cases, more historical context on a change can be easily found by going back to the mailing list discussion or the pull request conversation.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250