If you’re working as part of a team, conflicts in game development are bound to happen. And no, I'm not talking about the kind that happens when the designer wants more features while the programmer’s saying, 'We don’t have the time!'—although that’s a common one, too.
Here, we’re talking about version control conflicts.
With their mix of code, art assets, and other resources, game projects are particularly prone to version control headaches. Whether using Git, Perforce, or Plastic SCM, you’ve likely faced the dreaded moment when two team members edit the same file. Maybe it’s a script, a prefab, or a texture—either way, you’re stuck figuring out whose changes stay and whose get reverted.
But resolving conflicts in game development doesn’t have to be a nightmare! Understanding how version control handles your files and how to manage merge conflicts effectively can save your project from significant headaches.
In this article, we’ll go through the common types of conflicts you’ll face in game projects, from code clashes to asset overwrites, and how Diversion can help you resolve them gracefully, thanks to a set of dedicated features.
So… when do you get conflicts, really?
Solving merge conflicts in a collaborative game development project with version control is a common challenge. When multiple developers work on the same files and you want to keep a clear history of your project's evolution, you need to be very organized.
The problem in a nutshell
Merge conflicts occur as soon as two or more people make changes to the same file and attempt to reunify those changes afterwards (either in the same branch, or by merging multiple branches). And this can happen for all kinds of game files: scripts, levels or scenes, assets, configuration files, etc.
Plus, in the case of assets or large resources (such as images, 3D models, videos…), because those files are usually stored in binary format, there is virtually no way to “isolate” the different parts of the file. Meaning that if two people in the team edit it at the same time, they’ll almost always create a conflict.
So yep - in game dev, conflicts can appear in many cases!
The most common sources of conflicts
Just to give you an idea, here are important events in the lifecycle of a version controlled-project that may create conflicts:
- First of all, if two people in the team start from the same reference commit and each work on some edits on the same files, and then try to commit their new work in parallel, you’ll get a conflict.
- Similarly, if those two people work on their edits in different branches and then try to re-merge those branches together as one, then you’ll get what we call a “merge conflict” (because the issue will appear at the time of merging the branches).
- And of course, if you try to revert a previous commit, it’s possible that the modifications that were added since then create some conflict with this previous state of the repository, and so you’ll get a conflict.
Let’s be honest, those are pretty basic version control-related actions. So this shows you how quickly a conflict can appear, and why it’s important you learn how to deal with those.
But luckily - as we’ll see in the last section, when using Diversion, there are some tricks you can use to avoid those bad situations and keep your repo clean throughout the development!
How to solve conflicts the proper way
A quick run-down of how to solve a conflict
Before getting into more high-level stuff, let’s go through a quick reminder of how conflicts are actually resolved from a practical point of view - and do a demo of how to (create and) solve one with Diversion.
As we said before, conflicts arise at the time of a commit, if the version control tool isn’t too sure what version is “true” anymore: is it the one that you’re trying to add right now, or the one that was already stored beforehand and that you “ignored” (or forgot to check existed)?
So, to really understand how this situation can occur, and what to do to resolve a conflict in Diversion, we’re going to look at a very simple example with just a single text file.
Setting up our demo repository
In this article, we’re not going to dive into all the details on how to install and set up your Diversion tools. If you’re curious, you can check out the official docs, over here :)
Here, I’ll focus mainly on the Diversion Desktop app, and so first I’ll create my new project, called “demo-conflicts”, and open it in the app to get this start-up screen:
You see that, for now, Diversion auto-created an initial commit and a .dvignore file but, other than that, the repo is empty.
Creating our conflict
So suppose that, now, I create a new text file in this folder named hello.txt, and I commit it to the repo, like this:
We now have two commits, both on the default main branch, and our hello.txt file currently contains only the following:
hello world!
Alright, now - let’s say that we use the Diversion Desktop app to create (and auto-switch to) a new branch called “test” in our repo:
Then, on this new “test” branch, we’ll modify our hello.txt file to add some specific content:
hello world! (this is a test)
When we come back to the app, we see that we can commit the changes on our file in our current branch, so the “test” branch:
And we thus get our third commit on this branch:
But, now, suppose that we switch back to the “main” branch:
And we re-update our hello.txt file, but with some other extra content, such as:
hello world! (in main branch)
Then, what would happen?
Spotting a conflict in Diversion
When we go back to the Diversion Desktop app, you’ll notice that our file now has two indicators:
- The orange square tells us that it was modified since the last commit on our current branch. (And, indeed, on this branch, the file went from containing “hello world!” to “hello world! (in main branch)”.)
- And the purple warning tells us that it was also modified on another branch. We can even click on it to get some extra info:
This is really cool, because it means that you’ll always see the risk of conflicts before they happen. This is different from other famous version control tools like Git, for example, where you’re not kept aware of the other branches - you have to actively probe your repository before taking any action to make sure there won’t be any conflicts.
Diversion therefore makes it easy to spot and dodge a lot of conflicts, simply by actively checking the overall state of the repository for us and warning us ahead of time. (Which is possible because Diversion is cloud-based, and centralised, and all your repo info is thus synced on the server in real-time!)
Resolving a conflict in Diversion
But suppose that you didn’t see that purple warning, or you just ignored it for some reason. So you decide to commit your changes on the “main” branch with this other version of the hello.txt file.
At that point, you therefore have two branches (“main” and “test”) with two versions of the hello.txt file updated in two different ways, in parallel, both stemming from the same initial commit:
This could happen if, again, you’re not careful about Diversion’s conflict warnings, or you have toggled off the automatic sync of your repo to the centralised cloud source:
In that case, if you decide to re-merge the “test” branch into your “main” branch later on, Diversion will show you an error message and tell you that there were conflicts during the merge, and that you need to resolve them before you can finish this branch merging operation!
What you need to do at this point is examine the files or parts of files that cause the conflict and, for each of these conflict points, pick which version you want to keep:
Finally, simply commit your merge resolution to wrap up the branch merge - and there you go! You’ve now properly re-integrated your changes from the “test” branch, into the “main” branch :)
Which means that you can safely delete the “test” branch and clean-up your repository and, in the end, you’ll have a commit history that looks like this:
So you see that resolving conflicts isn’t impossible, but it does require a few steps - and here we had a very simple demo case, so picking the right version didn’t have any real consequence, but in a real project, properly re-merging the different versions can be a bit of a headache.
Which is why, oftentimes, you’ll want to avoid those conflicts altogether!
Avoiding conflicts altogether?
Now, as we’ve said, conflicts mainly arise when you don’t pay attention to the edits the rest of the team might have made in your absence. Which means that, to avoid conflicts as much as possible, in most VCS, you need to:
- Fetch or pull changes when you start your working session to be aware of any pre-existing change.
- Modularise everything you can - use prefabs and sub-scenes to allow multiple designers to modify the project without them touching the same file, chop your scripts in a logical way to let developers progress on multiple features in parallel…
- Communicate with the rest of the team! This is still the best way to avoid conflicts :)
All that is very nice, but it does put a lot on the user, doesn’t it? Couldn’t we automate all this a bit more?
Handling conflict easily thanks to Diversion’s tools
Ok - we’ve seen that conflicts are prone to happen in game dev and that, although they’re resolvable, they’re a pain to manage. So how do modern versioning tools like Diversion help you in that regard?
Well, first of all: because it’s easy-to-use, very clear from the get-go and completely available via a UI (contrary to Git for example that is still mainly used in command-line), Diversion is actually usable by all the members of your team without too much effort. Sure, if they’re not used to VCS, they’ll have to learn the different steps to perform - but at least, they’ll have nice visual indicators (and confirm panels!) to guide them all throughout the process, and avoid them mistakenly deleting or overwriting something.
(And because the service handles both text files like scripts and large assets, meaning you version everything in the same place, you don’t have the famous problem of using the wrong version of an image or a model… and similarly, the problem of overwriting said version.)
In Diversion, you also get a live display of which file is currently being edited by you… or any other member of the team! Which means that you always know if you’re running the risk of a conflict by working on this file or not :)
Of course, this doesn’t mean you should just stop talking to the other members of your team. However, it reduces the chance that you decide to do this task just at the same time as your colleague.
Again, this is possible because Diversion is a cloud-based solution that centralises the data online, and automatically uses this source of truth as reference for everyone.
And guess what? This also works cross-branch, and it will happen as soon as someone saves their changes locally, to warn you as early as possible!
Plus, in the near future, Diversion should add more granular permission settings which will make it even easier to protect your files from messes and keep everything neat and tidy!
So, as you can see, this VCS lightens the load on the developers and artists - all that’s really left to do for your team is to choose how to organise your project… and still keep it pretty modular, if possible, to help Diversion help you ;)
Conclusion
Resolving merge conflicts in game development can be a daunting task, especially when dealing with a variety of file types, from scripts to large binary assets. Traditional version control systems require careful management, constant communication, and a fair bit of manual intervention to avoid and resolve these conflicts.
But, with Diversion, which is tailored specifically for game development, these challenges are significantly reduced.
Diversion's user-friendly interface, real-time updates, and cloud-based centralisation make it easy to spot potential conflicts before they happen, reducing the likelihood of clashes. Its live display of ongoing edits and auto-locking of files in use further ensures that team members are aware of each other's work, helping to avoid accidental overwrites. By integrating all types of files into a single system and streamlining the conflict resolution process, Diversion allows developers and artists to focus more on their creative work rather than the intricacies of version control.
And with features like granular permission settings on the horizon, Diversion might just make game development even smoother and more efficient for teams of all sizes…
