Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Life with Unity + git + LFS: a rant and a call for help.

Discussion in 'General Discussion' started by bitinn, Mar 30, 2019.

  1. bitinn

    bitinn

    Joined:
    Aug 20, 2016
    Posts:
    961
    Hi all,


    I don't know about you, but I personally find making git and git LFS works properly with Unity increasingly difficult today.

    The concept of git and LFS are simple:

    - You put text-based files in git
    - You put static binary files in LFS
    - 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.)

    That's the end of version control with git, easy!

    But to do so effectively, you need:

    - Know what files are text-based and what files are binary, this is usually done by looking at file extensions.
    - Know where these files are, so you can include or exclude them by paths.
    - Know how to merge these files properly, either with git, or some third-party merge tool like UnityYAMLMerge.

    It used to be relatively easy, you can Google for a gitignore, and guarantee it works as intended.

    Not today, let me explain:

    - .asset/.unity files can be text or binary or both:
    - a simple scriptable object? text
    - lighting data or terrain data or nav mesh? binary
    - text mesh pro font asset? both (because you can store binary data in YAML)
    - a unity scene with pro builder mesh in it? both (because these mesh are encoded as binary data)

    - things are generated without you knowing:
    - 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)

    - merge tool is no longer at fixed location:
    - With unity hub, we no longer install Unity at fixed location, hence unityyamlmerge location can change too, good luck updating it each time.


    So my git repo is never quite right, and there are probably other issues that I don't notice.

    I guess that's why many game dev hates git.

    /rant over, please share your version control strategy?
     
  2. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    5,358
    We only use LFS for textures. Lightmaps we treat as compile time data (even though it takes hours to compile). All other binary data we check into git. It have worked pretty well over the years.

    edit: Forgot .fbx btw
     
  3. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,956
    Our main programmer hosts a SVN (Subversion) repository. Everything we need to commit goes into that one repo.
     
  4. bitinn

    bitinn

    Joined:
    Aug 20, 2016
    Posts:
    961
    I should probably explain why we would like to setup git this way:

    - git is by-design distributed, which mean everybody owns a copy of the "entire history" of the repo.
    - this sounds very nice, until you realize everything ever committed into the repo, even on change and deletion, is still in the history.
    - this is why committing large binary files are so evil, it will force everyone to download every version of these files.

    Thus LFS and my semi- control freak rant.

    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.

    And 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. (like a .obj file)

    Anyway, 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.

    https://gist.github.com/bitinn/4a82d7dbdaff62163031d318c57cd62d

    (Spoiler: it's not easy.)
     
    CuriousPatient likes this.
  5. AndreasO

    AndreasO

    Joined:
    Sep 25, 2012
    Posts:
    90
    Unity should use extensions to denote whether it's a binary file or not. Right now it's the responsibility of the VCS to either know or guess this by some crude file name patterns. This is not reliable and before I even noticed this issue I lost every single terrin data I thought I had saved and versioned in my git repo using LFS...
     
  6. WallaceT_MFM

    WallaceT_MFM

    Joined:
    Sep 25, 2017
    Posts:
    394
    We're a bit lazy with our LFS. 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. 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. It isn't a problem for us, but it might be for someone else if you have limited hard drive space or something. Our decision was based on the idea that harddrives are cheaper than labor costs.
    Here's a fancy one-liner you can run in git-bash that I use to help determine what I should be putting into LFS. Note that this takes a while to run on large repos.
    { git ls-files && git lfs ls-files | cut -d' ' -f3-; } | sort | uniq -u | tr '\n' '\0' | du -b --files0-from=- | sort -g -r > sortOut.txt


    You'll want to cd to your git repo before running that. It will then output a file called sortOut.txt that will have a list of all the things that are in your git repo that are not already in lfs, sorted in descending order of size. I then threw the file extensions/paths of the largest files into our .gitattributes file until the largest things left were .cs files and meta files.
     
    jayliu-deloitte, jayliu50 and bitinn like this.
  7. Metron

    Metron

    Joined:
    Aug 24, 2009
    Posts:
    1,137
    Use SVN... There's no benefit in using git in game development.
     
  8. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    Unless you actually care about workflow and branching and things teams generally care about. Git alongside SVN/Perforce is fairly common and has been for quite a while. Optimizing workflows by using the best tool for the job. It's only tiny teams that see benefits from an all in one solution, and even there it's debatable IMO. It's more tiny teams don't have the experience to know how to set things up well.
     
    Claytonious, Havokki, mowax74 and 3 others like this.
  9. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    What benefits does SVN have over Git for this particular use case? Isn't it going to run into exactly the same problems with not knowing binary vs. text and storage of large binary files?
     
    MadeFromPolygons likes this.
  10. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    4,044
    I was considering a switch from GIT to SVN for next project. I used to use SVN a long time ago and always found it pretty straight forward. GIT has some nice features though, I really appreciate git stash for example.

    Anyone have a real practical comparison? I've heard SVN handles binary more efficiently in general.
     
  11. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    Right, I see. It's because SVN only keeps the current version of checked out files on local machines.
     
  12. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    4,044
    Oh, so thats the advantage for binary - just no local change log?
     
  13. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    As far as my brief Googling turned up, yeah. As far as I know (I haven't tried it myself because it hasn't become a problem) that's solved by Git LFS, which splits large binaries into separate storage with different rules.
     
  14. Metron

    Metron

    Joined:
    Aug 24, 2009
    Posts:
    1,137
    SVN has no local repository. Binary files are handled without any problems.

    The LFS is a system added to git because they ran into problems with binary files. I don't see any real benefit of having a local repository with history. The same can easily be achieved by using branches. In fact, I actually see local repositories as a problem: if the developer commits in his local repository but doesn't push to the master branch, all work is lost if his HD fails.
     
    Deleted User likes this.
  15. sandstedt

    sandstedt

    Joined:
    May 24, 2015
    Posts:
    67
    Having a local copy of the whole history is GOLD in my option. Super easy to go back in time and see what have changed and checkout that directly without an internet connection.

    And not to mentioning the security to have the entire GIT project backed up on every persons computer, in case the GIT server would crash for some reason.
     
    Havokki and creepteks like this.
  16. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    5,358
    There is a reason SVN have lost the race to git, distributed versioning is just so much better, more so in enterprise sized teams
     
    Claytonious, Havokki and creepteks like this.
  17. Thom_Denick

    Thom_Denick

    Joined:
    May 19, 2014
    Posts:
    15
    Wow someone in 2019 advocating for SVN. You never know what you'll run into on the Unity forums!
     
  18. Metron

    Metron

    Joined:
    Aug 24, 2009
    Posts:
    1,137
    Wow... Someone in 2020 debunking an old thread... Without making any point why my arguments are invalid...
     
  19. benthroop

    benthroop

    Joined:
    Jan 5, 2007
    Posts:
    262
    If you like branching and using binaries without pain check out PlasticSCM. It really works!
     
  20. Neto_Kokku

    Neto_Kokku

    Joined:
    Feb 15, 2018
    Posts:
    1,751
    Except when you use LFS Git is no longer really distributed. Also, non coders can barely adapt to the update/commit flow, in my experience getting them to follow the commit/pull/push flow (in that exact order, don't you dare pull before committing) is a struggle.
     
    Deleted User likes this.
  21. Ziplock9000

    Ziplock9000

    Joined:
    Jan 26, 2016
    Posts:
    360
    Unfortunately, it's more expensive than several other enterprise solutions out there for the storage, which is the main statistic for indies. Also the price scaling is much worse too.
     
  22. benthroop

    benthroop

    Joined:
    Jan 5, 2007
    Posts:
    262
    It's been a few months and I actually agree with you now. Shortly after I wrote my message, Unity acquired PlasticSCM. In doing so they changed their plans to push almost all users into their cloud offering. The hosted version is over $20/user per month, which is out of range for most every small shop.

    It's one thing to use a proprietary source control software. It's another to be proprietary AND have your stuff locked in the cloud. So, I'm moving away from Plastic. But the only reason I can even do that is because Github + LFS has been pretty dang good. I would probably look at Plastic again for a really large project, but for things under 100GB, I think Github + LFS works.

    I've been a user and fan of Plastic for several years, and shipped games with it. It's great software at its core. I hope that Unity does something great with it that moves it beyond the current state.
     
  23. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    Azure devops + LFS works perfect for us. I love distributed versioning.
     
  24. perholmes

    perholmes

    Joined:
    Dec 29, 2017
    Posts:
    296
    I keep finding this thread after trying to use Plastic SCM for a while and wanting to go back to Git LFS, so I run through all the arguments for/against from scratch one more time.

    Plastic SCM has always been weird for me. I may just be unlucky, but I feel that I confront a new bug on almost every commit. Now in 2022.1a with Plastic inside Unity, when I commit, I get an error that it couldn't commit, but it was committed anyway, and then immediately two material files come up as changed, needing another commit. Rinse and repeat.

    The details don't matter, the problem is just that I've been through something similar probably 40 times with Plastic SCM, and I haven't used it that much, so this paints a picture for me of a piece of software that's only barely holding together. I have only very few memories of committing something to Plastic and not having some error that I didn't understand and that tech support seemed puzzled about.

    So I'm going to give it an honest shot at making Git LFS work. Github now has $5/50GB/month LFS pricing, so you don't have to fear scaling. I've had few problems ever with Git, but I have had things happen with LFS I didn't understand. But this time, I'll seriously try to work through them. I'm just not comfortable with Plastic anymore. Git has been 100x more stable and predictable for me.
     
    Ghosthowl likes this.
  25. bitinn

    bitinn

    Joined:
    Aug 20, 2016
    Posts:
    961
    Today we discovered a truly hideous behaviour in one of Unity's import workflow:

    - As readers might be aware, Unity support
    modelName@animationName.fbx
    convention where Unity is able to automatically collect all these animations under the file named
    modelName.fbx


    - This sounds very nice until you realize the mechanism it uses: It saved the GUID of each animation into the meta file of model fbx, using the
    referencedClips
    property.

    - Now, what if you have a animation file named like this:
    @animationName.fbx
    ?

    - Bad news, Unity automatically add this GUID to any other meta file in the same folder.

    - So if you have
    @Walk.fbx
    ,
    Santa.fbx
    ,
    Guy.fbx
    , both Santa and Guy will reference GUID of Walk.

    - And when you add
    @Run.fbx
    in this folder, both Santa and Guy's meta will have to change again, otherwise your colleague's git history are wrong.

    - Maybe we can contain it, when does Unity refresh these meta files anyway? It's undetermined. It doesn't always happen on import, and once your referencedClips are filled, you cannot move Santa to another folder then re-import to flush those GUID out.

    Now imagine an average user of git trying to figure out these behaviours.

    Unity has too many magic in it to be used with git properly, across a large team.
     
    Deleted User and neginfinity like this.
  26. fauzannr

    fauzannr

    Joined:
    May 2, 2020
    Posts:
    4
    Does anyone know why the FBX file configuration always reset when tracked on git LFS? I have a large model FBX file, where I've converted it from a generic model to humanoid but then, it turn back to generic after I pulled it from GitHub
     
  27. Neto_Kokku

    Neto_Kokku

    Joined:
    Feb 15, 2018
    Posts:
    1,751
    Did you add the corresponding .meta file that's right next to the .fbx to git? All configurations are stored in it. More importantly, it also stores the asset GUID, which is what Unity uses to reference things. If you don't add the .meta, a new GUID will be generated when someone clones and all references to that asset will be lost.
     
  28. Andy-Touch

    Andy-Touch

    A Moon Shaped Bool Unity Legend

    Joined:
    May 5, 2014
    Posts:
    1,479
    Based on my experience of using most common version control systems, Git/LFS are a big no-no when it comes to projects bigger than a prototype/small-scale demo. As soon as assets start to get big you will just run into so many problems.

    Always switch to something that can handle the size and workload better (SVN, Plastic, Perforce, etc), or just start with one of them from the beginning. We are using Plastic on a project internally for an unannounced game and I can say for sure that Git/LFS would not be usable at all for our workflow and asset handling.
     
  29. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    5,181
    Does "bigger" here refer to just sheer gigabytes amount of content?

    What sort of problems did you face?

    I have been using Git/LFS without problems, though maybe my project might fall into what you consider small-scale, that's why I ask. (my total storage is less than 100gb, and i never send more than 2gb at a time.)
     
    Peter77, NotaNaN and angrypenguin like this.
  30. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,589
    +1, I'm interested in the specifics as well @Andy-Touch
     
    MadeFromPolygons likes this.
  31. Neto_Kokku

    Neto_Kokku

    Joined:
    Feb 15, 2018
    Posts:
    1,751
    It's not that it doesn't work, it does, but there are pain points that require extra planning/navigation or only show up way later:

    - The support for locking binary files is not as robust as in the other solutions and can cause confusion due to git having distributed history.

    - It's hard to prune the repo's LFS history of you start to run low on storage space in your LFS host.

    - In my experience, merging text files which are stored in LFS can be finicky. This is the case for unity scenes, which are usually text but can grow quite large so they are better off in LFS.
     
    Peter77 and BIGTIMEMASTER like this.
  32. Metron

    Metron

    Joined:
    Aug 24, 2009
    Posts:
    1,137
    Hence why I said use SVN 3 years ago
     
  33. bitinn

    bitinn

    Joined:
    Aug 20, 2016
    Posts:
    961
    In short, it's not the amount of data that cause problems.

    It's the team size and different level of expertise on git usage that will give you headache.
     
    BIGTIMEMASTER likes this.
  34. Andy-Touch

    Andy-Touch

    A Moon Shaped Bool Unity Legend

    Joined:
    May 5, 2014
    Posts:
    1,479
    Mostly size of assets increasing; especially when it comes to larger textures.
     
  35. retrocloudstudios

    retrocloudstudios

    Joined:
    Feb 17, 2022
    Posts:
    1
    Yeah, just came across that now lmao. Pushed my LFS commit to Git and it takes like 20 minutes just to push the Assets :/
     
  36. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    How much (in file size) are you pushing, how fast is your connection, and where's the repo hosted?
     
    MadeFromPolygons likes this.
  37. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,967
    Im pushing 2-5gb at a time and it takes around 5 minutes max - what is your connection speed? It sounds like you are on potato internet unless you are pushing a serious amount of GB (like AAA levels of GB). If you are pushing AAA levels of GB I have to ask - why? what are you possibly doing that uses that much data to need to push each time (apart from the initial push to LFS which ofcourse will be longer than usual pushes)?
     
  38. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    We have shipped several largeish games on Git, never run into any big problems. Noticeable things are just:

    - Use your own server. GitHub and competing cloud services (including whatever Unity's offering) needs to put in speed and storage limits to maximize profits. If you want your source control to be as fast as possible, put it on a computer you own with a fast SSD and a fast CPU. Use a cloud service for off-site syncs, but the place you're pushing/pulling from should be a fast server. If you're in an office, you hit the server over the local network, no the internet.
    This is general advice, not just for Git. Don't buy your employees computers with threadrippers and 3080's and have those computers sit waiting on GitHub's download speed.

    - You don't really need LFS unless you're pushing very large lightmaps a lot, and then you only need for those. Unless your server is a literal potato (or a cloud service), it'll handle large fbx files and textures fine.
    Honestly you'd get a better looking game if you skipped baking light, cut some fidelity and spent the same amount of time iterating on realtime lights, but that's a different discussion.
     
  39. Andy-Touch

    Andy-Touch

    A Moon Shaped Bool Unity Legend

    Joined:
    May 5, 2014
    Posts:
    1,479
    Sure, every studio is going to have different experiences! Depends on what the studio is making. :D
     
    MadeFromPolygons likes this.
  40. eduardofreire

    eduardofreire

    Joined:
    Jan 24, 2022
    Posts:
    6
    Hello guys
    After some research and digging we got to this .gitattributes file, that is really addressing our needs and most importantly, has a header explaning the main topics that we had doubts / issues with.

    It's important to read it camly and understand what you're doing / want, but in general should be a good guideline.

    Finally, please be careful of changing files from and to lfs indiscriminately, as you might need to fix them manually later.

    line 29 is where we define
    uselfs


    Code (JavaScript):
    1. ####
    2. ##
    3. ##    Git Attributes file
    4. ##    Be VERY CAREFUL when adding stuff here.
    5. ##    Official Documentation: https://git-scm.com/docs/gitattributes
    6. ##
    7. ##    Some useful attributes (effects) are:
    8. ##    • text: Use for text files that should be mergeable.
    9. ##        We recommend against using "-text". Use "binary" instead
    10. ##    • eol=lf: Use to enforce line endings on any text file
    11. ##        (even if they aren't supposed to be merged).
    12. ##        Never use "eol=lf" with "binary" or "-text"
    13. ##    • binary: Use for files that are not suposed to be merged.
    14. ##        built-in macro attribute "binary" is equivalent to:
    15. ##        [attr]binary -diff -merge -text
    16. ##    • merge=unityyamlmerge: This forces git to resolve merges
    17. ##        ONLY using this tool. ONLY .prefab and .unity files
    18. ##        should have this. If the tool is not installed,
    19. ##        its equivalent to "-merge"
    20. ##    • -merge: This forces git to NOT TRY TO MERGE the files.
    21. ##        All binary files should have this.
    22. ##
    23. ####
    24. ##
    25. ##    When Using Git LFS:
    26. ##    We need to add filter=lfs diff=lfs merge=lfs to a lot of file types.
    27. ##    To avoid adding these tags to a lot of lines,
    28. ##        we define the custom attribute below (that includes the 3 tags):
    29. [attr]uselfs  filter=lfs diff=lfs merge=lfs
    30. ##
    31. ##    Enabling diff files support in LFS
    32. ##        According to: https://github.com/git-lfs/git-lfs/wiki/FAQ
    33. ##        To enable diffing LFS files, EVERY developer must
    34. ##        configure their own git environement.
    35. ##        To do this, just open a git console and run:
    36. ##            git config --global diff.lfstext.textconv cat
    37. ##
    38.  
    39. #### Unity ####
    40. *.cs                     text eol=lf diff=csharp
    41. *.cginc                 text eol=lf
    42. *.shader                text eol=lf
    43.  
    44. ##    Common Files
    45. *.unity                    text eol=lf -merge
    46. *.prefab                text eol=lf -merge
    47. *.asset                    text eol=lf -merge
    48. *.mat                      text eol=lf -merge
    49. *.anim                     text eol=lf -merge
    50. *.playable                text eol=lf -merge
    51. *.meta                    text eol=lf -merge
    52. *.controller            text eol=lf -merge
    53. *.spriteatlas            text eol=lf -merge
    54.  
    55. ##    "physic" for 3D but "physics" for 2D
    56. *.physicMaterial2D        text eol=lf -merge
    57. *.physicMaterial        text eol=lf -merge
    58. *.physicsMaterial2D        text eol=lf -merge
    59. *.physicsMaterial        text eol=lf -merge
    60.  
    61. ##    Specific assets exceptions (should come after generic definitions)
    62. ##    Generated NavMeshes, Terrains, and UMA slots are always binary,
    63. ##        even if unity serialization is set to "force text"
    64. NavMesh.asset            binary uselfs
    65. **/Terrain*/*.asset     binary uselfs
    66. *_Slot.asset             binary uselfs
    67. LightingData.asset         binary uselfs
    68. *.cubemap                binary uselfs
    69. *.unitypackage           binary uselfs
    70.  
    71. ##    FMOD
    72. /Assets/Plugins/FMOD/lib/mac/** filter=lfs diff=lfs merge=lfs -text
    73. *.bank filter=lfs diff=lfs merge=lfs -text
    74.  
    75. ##    Images
    76. *.ai        binary uselfs
    77. *.bmp       binary uselfs
    78. *.exr       binary uselfs
    79. *.gif       binary uselfs
    80. *.hdr       binary uselfs
    81. *.iff       binary uselfs
    82. *.jpeg      binary uselfs
    83. *.jpg       binary uselfs
    84. *.pict      binary uselfs
    85. *.png       binary uselfs
    86. *.psd       binary uselfs
    87. *.tga       binary uselfs
    88. *.tif       binary uselfs
    89. *.tiff      binary uselfs
    90.  
    91. ##    Audio
    92. *.aif       binary uselfs
    93. *.aiff      binary uselfs
    94. *.it        binary uselfs
    95. *.mod       binary uselfs
    96. *.mp3       binary uselfs
    97. *.ogg       binary uselfs
    98. *.s3m       binary uselfs
    99. *.wav       binary uselfs
    100. *.xm        binary uselfs
    101.  
    102. ##    Video
    103. *.asf       binary uselfs
    104. *.avi       binary uselfs
    105. *.flv       binary uselfs
    106. *.mov       binary uselfs
    107. *.mp4       binary uselfs
    108. *.mkv       binary uselfs
    109. *.mpeg      binary uselfs
    110. *.mpg       binary uselfs
    111. *.ogv       binary uselfs
    112. *.wmv       binary uselfs
    113.  
    114. ##    3D models
    115. *.3dm       binary uselfs
    116. *.3ds       binary uselfs
    117. *.blend     binary uselfs
    118. *.c4d       binary uselfs
    119. *.collada   binary uselfs
    120. *.dae       binary uselfs
    121. *.dxf       binary uselfs
    122. *.FBX       binary uselfs
    123. *.fbx       binary uselfs
    124. *.jas       binary uselfs
    125. *.lws       binary uselfs
    126. *.lxo       binary uselfs
    127. *.ma        binary uselfs
    128. *.max       binary uselfs
    129. *.mb        binary uselfs
    130. *.obj       binary uselfs
    131. *.ply       binary uselfs
    132. *.skp       binary uselfs
    133. *.stl       binary uselfs
    134. *.ztl       binary uselfs
    135.  
    136. ##    Compressed Archive
    137. *.7z        binary uselfs
    138. *.bz2       binary uselfs
    139. *.gz        binary uselfs
    140. *.rar       binary uselfs
    141. *.tar       binary uselfs
    142. *.zip       binary uselfs
    143.  
    144. ##    Fonts
    145. *.otf       binary uselfs
    146. *.ttf       binary uselfs
    147.  
    148. ##    Compiled Dynamic Library
    149. *.dll       binary uselfs
    150. *.pdb       binary uselfs
    151. *.so        binary uselfs
    152.  
    153. ##    Executable/Installer
    154. *.apk       binary uselfs
    155. *.exe       binary uselfs
    156.  
    157. ##    Documents
    158. *.pdf       binary uselfs
    159.  
    160. ##    ETC
    161. *.a         binary uselfs
    162. *.rns         binary uselfs
    163. *.reason     binary uselfs
    164.  
    165. ##    Collapse Unity-generated files on GitHub
    166. ##        (maybe works for Gitlab and Gitea?)
    167. *.asset     linguist-generated
    168. *.mat       linguist-generated
    169. *.meta      linguist-generated
    170. *.prefab    linguist-generated
    171. *.unity     linguist-generated
    172.  
     

    Attached Files:

  41. Ghat-Smith

    Ghat-Smith

    Joined:
    Aug 16, 2016
    Posts:
    48

    Your gitattributes is great and was helpful to complete mine
    I plan to define and use these two custom attributes on my side
    Code (CSharp):
    1. [attr]unityYAML text merge=unityyamlmerge diff eol=lf
    2. [attr]useLFS filter=lfs diff=lfs merge=lfs -text
    But i'm not completely sure....
    1. Any reason why you didn't put "binary" directly inside your uselfs attribute?
    2. Could you explain why you chose "binary" instead of "-text" for lfs elements?
    3. Why are you using -merge for Unity YAML files ? And not "merge=unityyamlmerge"?
     
  42. eduardofreire

    eduardofreire

    Joined:
    Jan 24, 2022
    Posts:
    6
    1. Main reason is to not mix up functionalities. Binary is about the file, LFS is about were you want it to be stored. Also, If I want to take a file from LFS, I can just remove uselfs and everything is fine. Dont need to remember that I need to add another tag.
    2. Readability. Using binary is clear to anyone that I want this file to be treated as binary. But -text is just fine, might be a better approach
    3. We dont use unityyamlmerge, we dont trust it. We want prefabs and scenes to be treated as binaries, no merge on them, so we dont have corrupted scenes / prefabs

     
    mowax74 and Ghat-Smith like this.
  43. Ghat-Smith

    Ghat-Smith

    Joined:
    Aug 16, 2016
    Posts:
    48
    Okay I see! Thanks for the details, everything seems relevant.
     
  44. mowax74

    mowax74

    Joined:
    Mar 3, 2015
    Posts:
    96
    Mhmm, and you don't think you could just say: If you don't push your data to the server and your local hard drive crashes, you lose your data? And that counts for SVN as well.
     
  45. Metron

    Metron

    Joined:
    Aug 24, 2009
    Posts:
    1,137
    Nope, because any push to SVN directly goes to the server.

    You lose data if you don't push at all, that is correct. But there are so many possibilities to fail with git... It's not fun...
     
    andyz likes this.
  46. bitinn

    bitinn

    Joined:
    Aug 20, 2016
    Posts:
    961
    It's been 4 years since my OP, I would like to report my experience since then:

    Yeah, either Perforce or SVN are vastly superior when working with Unity/Unreal.

    I loved git as a programmer, but it sure wasn't artist friendly, and we have tried to make this pipeline viable with multiple devs, it simply requires too much patch work.
     
  47. perholmes

    perholmes

    Joined:
    Dec 29, 2017
    Posts:
    296
    Hey, I was also a commenter in this thread, and let me also report experiences. We've settled on GitKraken + LFS + BitBucket + Pageant, which has been the smoothest workflow for us for years.

    I gave up on PlasticSCM (now Unity). Maybe I just didn't grok the paradigm, but after only a few commits, I'd screw everything up so much I'd be sending log files to a puzzled PlasticSCM support. I never looked a Perforce because of the pricing.

    I've had to walk back some of my early criticisms of LFS. Once all the parts are playing together, it's very smooth, besides you needing to be keenly aware of new file types not accidentally being committed to the main repo, but being put into .gitattributes for LFS handling.

    We use GitKraken because it has the best LFS support of any Git client, of which we gave every single one a shot. The most key feature is an LFS icon next to files that will be committed to LFS. It seems that SmartGit finally listened to our complaints and now also have a pre-commit LFS icon. I couldn't get it to work when I tried it, but it's too late, we're on GitKraken. The pre-commit LFS icon is the most core LFS feature. Once you commit a gigabyte file to your main repo by mistake, you're in trouble.

    We use Pageant for system agent authentication (this is on Windows), because GitKraken doesn't bring its own LFS, but needs to run it externally. Pageant is the only smooth way to get both GitKraken and LFS to see the same key.

    And then we use BitBucket, because LFS files are a first-class citizen, and can be inspected directly in the repo on the web.

    Honestly, it's now been years since I've made a commit mistake. In the beginning, it's important to never commit blindly, but inspect every single staged file to see if something should be in .gitattributes. But after a while, it stabilizes, and I haven't edited it for a long time.
     
    NotaNaN, Lymdun, rdjadu and 1 other person like this.
  48. Metron

    Metron

    Joined:
    Aug 24, 2009
    Posts:
    1,137
    We've been using PlasticSCM for quite some time for our Unreal projects. Workflow is easy enough for graphic artists who don't have deep knowledge of Git and LFS.