.gitattributes for Unity3D with git-lfs

.gitattributes

## Unity ##

*.cs diff=csharp text
*.cginc text
*.shader text

*.mat merge=unityyamlmerge eol=lf
*.anim merge=unityyamlmerge eol=lf
*.unity merge=unityyamlmerge eol=lf
*.prefab merge=unityyamlmerge eol=lf
*.physicsMaterial2D merge=unityyamlmerge eol=lf
*.physicMaterial merge=unityyamlmerge eol=lf
*.asset merge=unityyamlmerge eol=lf
*.meta merge=unityyamlmerge eol=lf
*.controller merge=unityyamlmerge eol=lf


## git-lfs ##

#Image
*.jpg filter=lfs diff=lfs merge=lfs -text
*.jpeg filter=lfs diff=lfs merge=lfs -text
*.png filter=lfs diff=lfs merge=lfs -text
*.gif filter=lfs diff=lfs merge=lfs -text
*.psd filter=lfs diff=lfs merge=lfs -text
*.ai filter=lfs diff=lfs merge=lfs -text

#Audio
*.mp3 filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text
*.ogg filter=lfs diff=lfs merge=lfs -text

#Video
*.mp4 filter=lfs diff=lfs merge=lfs -text
*.mov filter=lfs diff=lfs merge=lfs -text

#3D Object
*.FBX filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.blend filter=lfs diff=lfs merge=lfs -text
*.obj filter=lfs diff=lfs merge=lfs -text

#ETC
*.a filter=lfs diff=lfs merge=lfs -text
*.exr filter=lfs diff=lfs merge=lfs -text
*.tga filter=lfs diff=lfs merge=lfs -text
*.pdf filter=lfs diff=lfs merge=lfs -text
*.zip filter=lfs diff=lfs merge=lfs -text
*.dll filter=lfs diff=lfs merge=lfs -text
*.unitypackage filter=lfs diff=lfs merge=lfs -text
*.aif filter=lfs diff=lfs merge=lfs -text
*.ttf filter=lfs diff=lfs merge=lfs -text
*.rns filter=lfs diff=lfs merge=lfs -text
*.reason filter=lfs diff=lfs merge=lfs -text
*.lxo filter=lfs diff=lfs merge=lfs -text

For .gitignore, look for GitHub's official version at https://github.com/github/gitignore/blob/main/Unity.gitignore

Seems to me like the right way is:
*.asset ......
LightingData.asset .... -text
*TerrainData.asset .... -text

As @40detectives implied before but yours truly never noticed, since gitattributes uses the latter rule when multiple patterns match a file, it should treat everything as text, unless its name is LightingData.asset or TerrainData.asset etc. I don't define folders because each type of binary .asset has different implications.

TerrainData.asset, unless I'm mistaken, can be renamed safely from within the editor, without corrupting its data so you might want to use a naming convention(hence the * if you do sth like SceneName_TerrainData.asset).

LightingData.asset though, while it can be renamed from within the editor, at least for me, it doesn't work afterwards. Lighting is wrong, kinda like overexposed. Also if you rebake lighting, the result is again stored in LightingData.asset. So regardless of what you do, it will always be like SceneName/LightingData.asset.

There's a third type of binary .asset which is NavMesh. As far as I'm aware these are the 3 types. But I've never used it, so not sure of its quirks. It most likely has some.

So LightingData is always under a folder with the same scene name as the scene it's baked for. TerrainData is likely a free agent, you can put them wherever. NavMesh I assume is also a free agent.

Update:
TerrainData is the name of the type, but the default naming is New Terrain.asset. Still it's renamable so:
*-[Tt]errain.asset or *-[Tt]errainData.asset should be fine.
For LightingData though it has to remain as is and let the folder hierarchy differentiate them.

Update2: I found out about a nifty git command that can help you figure some things out if you're in a weird situation with attributes:
git check-attr

It tells you if a pattern of specific filepath has attributes and which they are. For example, using the above recommended rules:
git check-attr -a .asset
returns:

.asset: merge: unityyamlmerge
.asset: eol: lf

while based on the latter rule I set before:
git check-attr -a LightingData.asset
returns:

LightingData.asset: diff: lfs
LightingData.asset: merge: lfs
LightingData.asset: text: unset
LightingData.asset: eol: lf
LightingData.asset: filter: lfs

The LightingData clearly speficies that "text" is unset, so it's not text type asset, but binary.

The .asset though doesn't specify "text". To further verify you can do:
git check-attr text .asset
and you'll get:

.asset: text: unspecified

Documentation for gitattributes' text states that in the absence of text, it defaults to what core.autocrlf defines, which by default is true, so it treats it as text.

There is a case to be had for "text=auto" in letting git decide if the asset is text or binary, but I can't be sure about it, not having used it.