Categories
programming server admin

Unity: Git source control – a basic .gitignore

The most popular hit for “unity gitignore” is a post on the official Unity forums that was written by someone who doesn’t seem to fully understand how git works. Which was a little disappointing.

Before you commit anything to git, you MUST go into Unity’s menus and enable the “metadata” option (in settings, moves around a bit between versions). Without that, Unity’s internal data-bugs will corrupt your project if you ever merge (happens to us approx 1 time in 3 if we forget at start of project)

After a bit of trial and error, here’s a basic .gitignore for Unity that seems to work, and cut down the commit sizes by a factor of 4 immediately:

UPDATE: updated with a tried-and-tested gitignore that covers more things. Do please note the big WARNING though, or you’ll only have yourself to blame…

##################
# Unity ignores:
#
# !!! WARNING !!!
#
# … you MUST convert Unity to using Metafiles *before* you start using this .gitignore file,
# or you WILL lose data!
#
#####
#
# !!! WARNING !!!
#
# … don’t forget to [git add “*”] (quotes are required!) when adding new files, or git will silently ignore them
#

# OS X only (not needed on other platforms)
.DS_Store
*.swp
*.Trashes

# All platforms
Library
Temp
*.csproj
*.pidb
*.unityproj
*.sln
*.userprefs

10 replies on “Unity: Git source control – a basic .gitignore”

We tried Unity Asset server the best part of 2 years ago. It was a poor offering and was very expensive. Then we switched to svn instead. It worked fine. We’re using git elsewhere and that’s what I’d recommend, too.

The only source control systems unity does not play nice with are ones that use file properties as pseudo version control data (e.g. P4 uses read only flags to determine whether something has been checked out; it was pretty painful to use with Unity)

“unity does not play nice with are ones that use file properties as pseudo version control data” — which just goes to show how UTTERLY STUPID those SCM’s are.

(on a par with CVS’s “CVS is for distributed teams; but CVS is not thread-safe, so it cannot be used by more than one person at a time. Unless you’re happy with corrupted data – source files that silently change into random gunk”)

By Post Author

It’s unfortunate in P4’s case as, in terms of raw performance, it remains the fastest version control system I’ve used.

In terms of workflow, it feels like a quaint relic from an ancient civilisation, though.

I think that’s simply the long term lack of viable competition. They got extremely lax, even 10 years ago they’d already massively slowed down on innovating, seemed to be coasting on the sales + high recurring subs revenue.

I shall not shed a tear when they go down (sometime this decade, I think). They had a “top dog” position, and failed to do anything with it, just staganted their product. Such companies don’t deserve to remain leading tech suppliers :)

If I may offer my own git-specific .gitigore configuration, I have it set up as follows:

*.sln
*.userprefs
*.csproj
*.pidb
*.unityproj
.DS_Store
/Library/FailedAssetImports.txt
/Library/cache/
/Library/previews/
/Library/ScriptAssemblies
/obj
/Temp

I hope this helps someone.

I’m still experimenting with this. I sent some tech support requests to Unity, which they answered, but couldn’t be bothered to give anything useful (their answers were essentially: “1. Buy the pro version or **** off. 2. Leave me alone, I don’t know how Unity works either; I merely work here”)

Suffice it to say: it’s difficult to get the gitignore correct, and Unity has some very nasty bugs related to merging.

Comments are closed.