I created a clean git bare repo and pushed around 300MB of files to it (on the master branch). At this point, the git bare repo was 57MB in size. I then changed 10 files, 9 were small ~1KB source files and 1 was a 900K binary file. I committed these changes to another branch (dev_branch) and pushed to the bare repo. After this, my bare repo size is now 114MB (doubled in size from a fairly small commit). I'm doing this in a local test, nobody else has access, so the bare repo only has these 2 commits (on 2 different branches).
I was thinking only the changes would be stored and the bare repo size would barely grow from such a small commit, maybe the size of the files max (~1-2MB). Why did such a small commit cause the bare repo to double in size?
I was waiting for a commenter to post their answer as an answer, but I'll go ahead since they haven't.
The short answer (thanks to several people in the comments) is that git stores a complete snapshot for every commit, which explains the double size from the 2nd commit of a small change set. It doesn't stay this way though, as commits go on, git does do a lot of work to pack everything, including using blobs to store file contents in a way that duplicate files can point to the same blob instead of storing the blob twice. For my small example, I thought it would do this on the push, but that appears to not always be the case. I was able to run git repack -ad to return the size of the 2-commit repo to 57MB (about the same size of the 1-commit repo).