Our decision was based on the idea that harddrives are cheaper than labor costs. It isn't a problem for us, but it might be for someone else if you have limited hard drive space or something. The problem with our approach is that it uses a lot of LFS space and makes the git repo larger than it needs to be. We put essentially everything that isn't a text format or a meta file into LFS, and then some very large text files get stuffed in there too. obj file)Īnyway, I thought I should post my gitattributes and gitignore so everyone can take a look, it's by no means perfect or anything, just the things I have currently done to make my repo history lighter. I think things like NavMesh asset or Addressables' bin (which stores the player versioning data for content update build), are specially evil as they can change quite often.Īnd of course there are cases where you know a file is plain text, but because it's large and static, you commit to LFS anyway. Thus LFS and my semi- control freak rant. this is why committing large binary files are so evil, it will force everyone to download every version of these files. this sounds very nice, until you realize everything ever committed into the repo, even on change and deletion, is still in the history. git is by-design distributed, which mean everybody owns a copy of the "entire history" of the repo. I should probably explain why we would like to setup git this way: rant over, please share your version control strategy? I guess that's why many game dev hates git. So my git repo is never quite right, and there are probably other issues that I don't notice. With unity hub, we no longer install Unity at fixed location, hence unityyamlmerge location can change too, good luck updating it each time. merge tool is no longer at fixed location: Addressables put generated content under both /Assets/AddressableAssetsData/ and /Assets/StreamingAssets/ (I understand why it does it, but then it's up to me to tell git and LFS to exclude these generated content, or track them but face frequent changes) things are generated without you knowing: a unity scene with pro builder mesh in it? both (because these mesh are encoded as binary data) text mesh pro font asset? both (because you can store binary data in YAML) lighting data or terrain data or nav mesh? binary asset/.unity files can be text or binary or both: It used to be relatively easy, you can Google for a gitignore, and guarantee it works as intended. Know how to merge these files properly, either with git, or some third-party merge tool like UnityYAMLMerge. Know where these files are, so you can include or exclude them by paths. Know what files are text-based and what files are binary, this is usually done by looking at file extensions. That's the end of version control with git, easy! You exclude other stuffs like generated files (because they are auto-generated on compile, on build or at runtime, so no need to track them.) I don't know about you, but I personally find making git and git LFS works properly with Unity increasingly difficult today.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |