Git with Unity, for everyone

As any developer knows, using Git or any other versioning system is a must when working on a software project. This remains true when working on a game. What’s so special about game development specifically? Well, the usage of Unity, to start with, is going to add a layer of complexity especially for the merging process. A less obvious particularity is the variety of people having to use it, and believe it or not, non developers don’t necessarily know Git. How to help them work with it?

We won’t dive into the details of how Git works, we assume here that the reader has a basic understanding of what it is. Instead, we will focus on the particularities of using Git when working on a Unity project.

The .gitignore file

Unity generates a lot of local cache and files. We refine the content of our gitignore regularly. Since we started working with JetBrains Rider as IDE, we also excluded the related project files. Here is the version we used on the “Swordship” project:

*.csproj
*.sln
.vs/
*.db
*.opendb
*.idea
[Bb]uild/
obj/
Library/
Temp/
SwitchIL2CPPCache/
SwitchIL2CPPStats/
TestResults/
AssetBundles/
Blend/*.blend1

Assets/WwiseSettings.xml
# Wwise generated
GeneratedSoundBanks/
GeneratedSoundBanks*
IncrementalSoundBankData.xml
AkWwiseProjectData.asset
WwiseUnityIntegration_*_Src.zip
*.validationcache
.cache
*.wsettings

Assets/Plugins/Editor/JetBrains/
Assets/Plugins/Editor/JetBrains.meta
Assets/Plugins/JetBrains/
Assets/Plugins/JetBrains.meta
Assets/Plugins/Editor.meta

If you don’t know what you need, a generic .gitignore for Unity is available on github: https://github.com/github/gitignore/blob/master/Unity.gitignore

Git LFS

Git large file system is a must to work on projects in which binary files are frequent. After a tentative to keep a separated data folder, we chose to keep all the assets needed for the project in the git repository. This allows us to ensure that a simple checkout from master always builds the version we want. Here is the .gitattribute file we use to select the files handled by LFS:

*.png filter=lfs diff=lfs merge=lfs -text

*.jpg filter=lfs diff=lfs merge=lfs -text

*.jpeg filter=lfs diff=lfs merge=lfs -text

*.tga filter=lfs diff=lfs merge=lfs -text

*.fbx filter=lfs diff=lfs merge=lfs -text

*.bmp filter=lfs diff=lfs merge=lfs -text

*.mp3 filter=lfs diff=lfs merge=lfs -text

*.ogg filter=lfs diff=lfs merge=lfs -text

*.zip filter=lfs diff=lfs merge=lfs -text

Unity Scene Synchronisation

Unity scene files are likely to change every time a unity GameObject is touched. Although these are XML files, their content is not easily readable, let alone manually mergeable. A scene conflict is usually resolved by selecting fully one of the conflicting versions, which can lead to a loss of work. The best solution to that is also a good practice in Unity project architecture: work with independent prefabs.
When editing a prefab, only the prefab will change. When the prefab is instantiated several times with different parameters, the use of prefab variant will allow to consider each of them as a prefab without having to save any overload in the scene.
Following this practice significantly reduces the amount of work done on the scene object. Nevertheless, it can be useful to verify with the team that the scene is clear to work with when starting a task that requires editing it extensively.
Furthermore, try to minimise the amount of public variables that have a developer purpose only (like passing a reference). It will prevent game designers making conflicting changes with the developers.

Merge to master quickly

That’s also a recommendation for usual software projects. Unity might generate many conflicts even with great care during development. Don’t forget to review and merge frequently.

Non developer profiles

At Digital Kingdom, in addition to the developers, game designers and artists also work in Unity and have to use Git. We highly recommend it for small teams, as it will accelerate the development process and centralize all the necessary assets. Since Git is not an instinctive tool, learning it might be difficult for non developers, but once this is done, the collaboration quality increases a lot.

As a more personal approach within our team, we chose to simplify the designer and artist flow by giving them priority to merge. Concretely, they just ensure that the project runs on unity but can merge to master without review and solve conflicts with their scene change. Developers use a more standard approach including code review.

To conclude

Using Git not only for the coding part, but for the full Unity pipeline allowed us to better collaborate with all team members. Our projects are more stable with fully working project states properly versioned including all assets. The work of game designers artists is simplified and de-riskified by allowing to roll back any unwanted change.