Development Smoothies

How to blend the work together

When working on any big team project, especially video games, it’s important to be able to blend everyone’s work together. Whether it’s scripts or models, that’s where version control comes in. Version control automates the process for collaborators to share their work with each other and acts as a backup.

It’s important to note there are various forms of version control (Git, SVN, CVS, Unity Collaborate, etc.) and each of them have strengths and weaknesses. For example, Git is excellent at handling merging scripts and text files, but less facile with binary files (which includes media files such as images or videos). In terms of game development, Git is fine for solo projects, but I would be cautious using it with a team as there can be issues, especially relating to merging scene (level) files. SVN on the other hand is much better at handling binary files, and natively allows collaborators to lock files to prevent merge issues (Git can do this, but it requires a plug-in). The downside of SVN is you have to setup your own server, while Git there are many web servers setup already (e.g. GitHub, Bitbucket). My team uses SVN because it was recommended to us and we have had only a few issues. I would encourage you to do some through research before finalizing which form of version control is right for you and your team.

SVN window in Unity, shows adding, modifying, and locking files.

Regardless of which form of version control you use, the idea and overall process is the same. First, someone must create the initial project and upload that to the server. From there, there are two versions of project, a server copy and a local copy. The server copy handles most of the merging and is how everyone can share their work each other. Your local copy is on your computer and any modifications or additions you make to it, don’t affect the server copy. Once you are ready to share (or backup) your work, you push that to the server and then everyone can pull (download) it. (Note: Before you can push, you must pull the latest version). Everyone should be following this process frequently, especially when everyone is working on the project simultaneously. A good rule of thumb is to do this at least once an hour while actively working on the project. Generally, you want to avoid big pushes or going long periods of time without pulling as it can cause merging issues. Of course, more than anything, communication is key. Whenever a collaborator pushes a big push, they should communicate that so everyone can pull that as soon as possible to avoid any potential issues.

Like any other software, version control is not a panacea that will solve all issues of merging files. The most common issue with version control is merging issues, which usually occur when at least two collaborators work on the same file simultaneously and one pushes before the other. When the other pulls, it will be unsure of which version to use and will cause a conflict. There are two possible scenarios: (1) Using manual merging, both/all contributors can keep most of it not all their work and continue, which is usually only possible with scripts and text files; (2) The collaborators will have to determine which version to use and the other will lose all that previous work and must redo it. Neither scenario is desirable, especially the latter. To minimize this, collaborators should communicate which files they are working on and lock them if possible.

Notice in the upper left of the scene window, you can lock file to ensure that no else works on it.

Lastly, version control can also be referred to as source control. But I’ve been using version control for a specific reason. Each time you push, it keeps track of the changes in a log and creates a version of the project with those changes. In the event something is pushed and unexpected error(s) occur, you can revert back to a previous version, save without the changes, and push that as newest version.

I hope this has been insightful into learning how to merge each teammates’ work together. Again, do some research into which version control would work best for your team and project. Once you’ve done that, practice with it to get familiar with it and learn more about its’ capabilities. Ultimately, version control should help, not hinder, your project.

---

Author: Cameron Pyfferoen