Short Introduction to Version Control - VapaaLassi/TAMKUnity2024 GitHub Wiki
What is Version Control?
Version Control means technologies that make it easy to backup and distribute files to team members. It's an older, more powerful and complicated version of cloud storage services like DropBox, Google Drive etc.
Most of them use Git, which is a version control system that works by storing the smallest possible changes to files, which makes it a lot faster to share them with team members. It's works best with text files (especially code), but it can be used with anything. It also stores all the changes on your computer, instead of only online, so it's very fast to go backup in history or to save changes.
How do you use Version Control?
Some programmers will tell you that the only way to use version control is through the command line. This is not true, and you should not start with it. It looks like this: Instead you should use some of the visual version control tools, that will do everything that the command line version does, except it makes sense. There's lots of these, like SourceTree, Github Desktop etc., but they are pretty much the same. Here's the same thing as above in a graphical version control program:
Whichever one you use, the basic idea is the same, you see a list of changes to files, then you need pick which ones to upload to the project repository for other people to get (or to backup for yourself). In the graphical versions, you just click checkboxes to pick them. Then you need to write a commit message describing what you did. A commit is just a packaged set of changes. When you have a commit, you can click a button to "push" or "sync" the changes to the main repository, which makes them available for everyone else.
Unity and Version Control
Unity works okay with version control, but it's not perfect. The code files are easy to work with and Git is even smart enough to figure out that if someone added some code to the beginning of one file and someone else to the end of it, it can merge these changes together without issue. Where it gets more complicated is with Unity scenes. They are giant blocks of text as far as the computer is concerned and if two people work on the same scene separately, make commits to it and try to sync them together, it will cause what Git calls a 'conflict' AKA it can't figure out how to combine the changes. There's some technical tools to make this possible, but usually the end result is that you keep the bigger set of changes and then redo the others.
The way to avoid this is working in Prefabs instead of Scenes. So player characters, background music, mixers, audio manager etc. should all be their own prefabs. If you change a prefab that is already included in a scene, there will be no changes (and no possibility of conflicts) to the scene itself. From the Git standpoint, the scene just knows to create a prefab there, but not what exactly is or has changed in the prefab.
Audio files and Version Control
Git also doesn't manage large files that well, and audio, especially music, tends to be pretty big. There are things like Git LFS (Large File Storage) that tries to solve it, but that needs to be set up. Also, sometimes, if you are using WWise, FMOD or other middleware, the project files for that might be a completely separate repository, so to run the game with new audio, you need to build the FMOD project, copy it over to the right folder in the Unity project and then run the game.
.gitignore and Unity
There's a file called .gitignore that marks which files are not included in the backups or shared with others. These depend on the program you are using as most of them tend to generate a lot of random stuff that just makes the program work, but are not needed to make the project work. For Unity there are ready made ones that are absolutely required to make version control work. For Unity it looks something like this:
#
# Get latest from https://github.com/github/gitignore/blob/master/Unity.gitignore
#
/[Ll]ibrary/
/[Tt]emp/
/[Oo]bj/
/[Bb]uild/
/[Bb]uilds/
/[Ll]ogs/
/[Mm]emoryCaptures/
# Asset meta data should only be ignored when the corresponding asset is also ignored
!/[Aa]ssets/**/*.meta
# Uncomment this line if you wish to ignore the asset store tools plugin
# /[Aa]ssets/AssetStoreTools*
# Autogenerated Jetbrains Rider plugin
[Aa]ssets/Plugins/Editor/JetBrains*
# Visual Studio cache directory
.vs/
# Gradle cache directory
.gradle/
# Autogenerated VS/MD/Consulo solution and project files
ExportedObj/
.consulo/
*.csproj
*.unityproj
*.sln
*.suo
*.tmp
*.user
*.userprefs
*.pidb
*.booproj
*.svd
*.pdb
*.mdb
*.opendb
*.VC.db
# Unity3D generated meta files
*.pidb.meta
*.pdb.meta
*.mdb.meta
# Unity3D generated file on crash reports
sysinfo.txt
# Builds
*.apk
*.unitypackage
# Crashlytics generated file
crashlytics-build.properties