I think it’s generally agreed upon that large files that change often do not belong while small files that never change are fine. But there’s still a lot of middle ground where the answer is not so clear to me.
So what’s your stance on this? Where do you draw the line?
The main downside is Git downloads all history by default, and so any large files will bloat the download for people cloning your repo forever. It isn’t about binary vs text. It’s just the size that matters.
If it’s a build artifact, put it in a registry. If it’s resource type files, Git LFS can be used if it’s not an absolute ton.
hiss The point of source control is keeping a history of the code that produces binary artifacts. For convenience’ sake or because of some wild project-specific constraints people can do all kinds of things but IMO binaries in source control are yucky yucky bad bad bad.
I agree that the repository should only contain source files, not the output of the build process. However, in some cases (like icon images) the source files may be binary. I think small binaries that are required to build and/or run the software, and that are not an output of any build process, do make sense to put in the repository.
That’s not really responding to their point. Are you saying that there are no project resources that aren’t (or couldn’t be) encoded as text representation in any conceivable project that is stored in a git repo?
I agree with your general point. I’m just curious if you have some unique project pattern techniques that allow you to draw such a hard line so confidently.
I don’t like it, but if they’re part of the project files, then they belong in version control. I do worry about the challenges of combining the difficult-to-merge nature of binaries with the distributed workflows that Git encourages. While data doesn’t get lost, the inability to merge them may mean that someone needs to spend extra time re-performing their changes if they “lose” the push/merge race.
Game engines have been doing a better job of transitioning away from large monolithic binaries by either serializing them in somewhat mergeable text files or at least splitting them into large numbers of smaller binaries to reduce file contention.
Git LFS does offer the ability to off-load them from the repository, reduce download and checkout times as well as the ability to lock files (which does introduce centralization…), but it doesn’t seem to be as ubiquitous and can be more expensive to use, depending on the team’s options for Git repo providers.
Note: I assume you mean binaries as in “non-text files”, not build artifacts, which definitely don’t belong in version control at all.
