Integrating Integrations in the Unity gitignore (vscode, Rider, FMOD, Blender)

[CaseyHofland]

Reasons for making this change:
I'm Casey, a fourth year bachelor student at the HKU (Hogeschool Kunstacademie Utrecht) studying in Unity Development. Every now and again I help teams out with their github, and I see a lot of conflicts arise that could have been avoided, so I've been questing to improve the unity github experience for my peers and students to come. This PR is part of that initiative.

Important note on flexibility:
The commits for this gitignore have been designed with flexibility, or rather rebase, in mind. If some part of this ignore is rejected, let me know which commit specifically is the culprit so I can rebase it, remove it, and we can all forget it ever existed.

Links to documentation supporting these rule changes:
d8cafd2, 37bc450 have no source but are literally cache directories.
d4c81e8 taken from FMOD Unity Integration Using Source Control
682c73e What is a blend1 file and why do you (not) need them? blend1, blend2, blend3, etc. files are autosave backup files. If you have a habit of using blender in Unity, then you probably don't want to push all these files with your final result.

[Creator13]

I wouldn't put .idea and .vscode in there, as these folders can contain useful files like run/debug configurations or team-shared settings like code conventions. Experienced users will definitely want to keep these folders and will be scratching their heads when the editor-specific gitignores aren't working properly!

Something can be said for preventively including the Rider gitignore inside the Unity ignore, as many people use either ReSharper or Rider with Unity, but I guess it's safer to stick to convention and keep those in their separate ignores.

[NegInfinity]

I wouldn't put .idea and .vscode in there, as these folders can contain useful files like run/debug configurations or team-shared settings like code conventions. Experienced users will definitely want to keep these folders and will be scratching their heads when the editor-specific gitignores aren't working properly!

Something can be said for preventively including the Rider gitignore inside the Unity ignore, as many people use either ReSharper or Rider with Unity, but I guess it's safer to stick to convention and keep those in their separate ignores.

.vscode is something I always add to unity gitignore because it contains user configuration, and in case of unity the configuration depends on ABSOLUTE path to project library folder, which makes it useless in a team. In practice it is highly likely that people iwll end up stamping this sort of file with their local changes, cluttering the git history with junk.

I also made similar suggestion before.

#3810

[CaseyHofland]

Removed 631b209 according to an earlier commit Unity: Remove exclusion for *.meta files.

Removed all the Global Gitignore additions based on general discussion in the Unity forums. Conclusion: these are by design meant to be in a Global gitignore (although I still think it's silly I have never heard of those before, are these really so underground?!)

Global Gitignore additions:

• 972a747
• 2057c1a
• 104cfad
• 9ab9307
• 4156fc6
• 921d8f0
• 4e31723

FMOD and Blender should in my opinion be added to the Unity gitignore as they have respected integration in the Unity software and, as is the point of this PR, may trip up beginners unnecessarily (especially the FMOD commit which may cause conflicts that should never have happened in the first place).

[CaseyHofland]

Update:
As this initiative is taking shape I've relaxed the goal a bit from "No More Unnecessary Unity Conflicts" to "Less Unnecessary Unity Conflicts".

This is largely due to me learning about global gitignores (you'd think after 2 years that they'd have popped up somewhere but oh well) which put me in an awkward position - if it's by design that Windows / Mac / Linux files are ignored via a global gitignore, but no "student or beginner" will know about global gitignore then how to best approach? Leading me to the conclusion that perhaps maybe our school is to blame for our lack of source control knowledge more than I realized.

This PR still has in my opinion some valid additions to the Unity gitignore and will remain just as active, only with a different goal in mind.

[KumoKyaku]

My common configuration https://gist.github.com/KumoKyaku/5f9488ffa965a51c93163d3e0003fb1a
My common large file configuration https://gist.github.com/KumoKyaku/a095df526f245d4265c3af21eb2efb0d
Hope that helps.

[CaseyHofland]

My common configuration https://gist.github.com/KumoKyaku/5f9488ffa965a51c93163d3e0003fb1a My common large file configuration https://gist.github.com/KumoKyaku/a095df526f245d4265c3af21eb2efb0d Hope that helps.

Wow, there is obviously a lot of effort put into this, especially your lfs file! I have taken lines from it for my own personal use: there's a few file types I missed, where do you get this information?!

One trick you'll appreciate is something I do for some Unity specific files - instead of specifying how to merge in .gitattributes I use this:

# Collapse Unity-generated files on GitHub
*.asset linguist-generated
*.mat linguist-generated
*.meta linguist-generated
*.prefab linguist-generated
*.unity linguist-generated

Read the motivation for this here!

If you click the link and scroll up you'll also see the current .gitattributes I use.

---

Also, sorry for responding so late, we hit crunch time for our school project last week :P

EDIT:
I noticed an error in your file:

*.physicsMaterial* filter=lfs diff=lfs merge=unityyamlmerge -text

# Should be:
*.physicMaterial filter=lfs diff=lfs merge=unityyamlmerge -text
*.physicsMaterial2D filter=lfs diff=lfs merge=unityyamlmerge -text

Notice the 'missing' s for physicMaterial. For some reason these names are not consistent in 2D and 3D on this one particular type.

[github-actions]

This PR is stale because there have been no updates in 90 days. It will close after 180 days of inactivity. Leave a comment if you want to keep it open 😄