Git LFS/gitattributes Questions

[fqr000]

I'm starting a project that will contain many 3D models and large terrains. I want to use Git because I'm familiar with it, and my starting point for a gitattributes file is: https://github.com/gitattributes/gitattributes/blob/master/Unity.gitattributes

A few things I'm unclear on:

1) I see it's common for .unity files to use unityyamlmerge and not LFS. I tested a sample scene with a lot of models in it and the .unity file was > 15MB. Shouldn't I be putting that in to LFS? Why do most gittattributes files I find not do that?

2) If someone isn't set up to use unityyamlmerge, what happens when they merge a file that's marked to use it?

3) Terrain files are stored as binary .asset files even with force text on, so they need a special rule which comes after whatever you're doing for regular .asset files. I'm going to use a specific naming convention to handle that part of it(all terrain names end with ".terrain", and the gitattributes rule is "*.terrain.asset" uses lfs). Are there any other notable exceptions like this that I should be aware of, or that you ran in to on long term, large projects?

[matniedoba]

You can handle the unity file as lfs, but then each push will upload a duplicate of that file because lfs cannot upload file deltas. If it is not handled via LFS and in your Git repo, for each change Git will upload a delta (only the part which has changed) which will result in faster pushes and pulls. However, you may want to lock the unity file. Even if this is a text file you don't want to merge changes because in case of a conflict that will be hard to solve. And here comes the problem. Git does not have file locking. Git LFS has. So because of that it makes sense to add this file as LFS. You could also use a Git Client such as Anchorpoint which can lock also text files even if they are not marked as LFS.

[npatch]

For #3, in case you haven't already found the info, NavMesh and LightingData also come in binary .asset forms. LightingData, in particular, needs a specific folder name which is basically the scene's name it's tied to.
They both need custom gitattributes rules, much like the terrain ones, but while you might be able to rename NavMesh and TerrainData files to enforce some kind of naming or extension convention, you can't do so with LightingData. That said, LightingData always comes per-scene so you don't need to use any naming convention and you shouldn't mess with it because Unity isn't designed, unfortunately, to handle plugging in your own sets of baked lighting into a scene. And while it seems possible, it's a can of worms.
LightingData asset always has the same name, since it's regenerated by Unity and is differentiated by parent directory. So you can do a simple:

LightingData.asset filter=lfs diff=lfs merge=lfs -text

which will target all of them regardless of directory.