Resolving Commit Conflicts
In almost every scenario, there are multiple developers working together to deliver a project. And while it’s helpful to have multiple people involved, it does increase the chance of creating conflicting versions of your project. But this is something that developers have known for decades.
On one of my recent projects, the team was forced to focus on one page for an entire day. This led to many conflicts which only slowed us down further and created frustrations within the group.
We eventually just started working in one version of the project to avoid them! Sometimes these issues cannot be avoided (such as a team-wide review of a single page) and you’re forced to deal with them.
Mendix’s low-code platform makes it easy to track versions and avoid conflicts. The Mendix Team Server uses Subversion (SVN) to manage project versioning. The Team Server stores the project source code and provides a way for the team to track changes.
When changes are made, the team server can intelligently update and control the most recent version of the entire project. When two team members alter the same page, Microflow, or domain model, this may result in a conflict.
In this post, I’ll walk through how conflicts occur and how you can resolve them.
How Conflicts Arise
Let’s assume there are two team members, Ryan and Lisa. Since the team server has the source code, there are three copies of the project. At the beginning, they are all equivalent:
Ryan makes a change (A becomes A’) and then commits it back to the Team Server, updating the Team Server version to A’.
Lisa then makes a different change (A becomes A’’).
Before Lisa can commit her project back to the Team Server, she must update her project to the most recent version. When the update is complete, Lisa receives a notification of the conflict.
Now that we have a conflict, let’s look into how to resolve it.
Resolving Conflicts
In our example, Lisa can’t commit her project until she has resolved the conflict. First, she has to find the conflict – which you do through the Changes dock (as specified in the notification).
Double click on the message to see what components are conflicted. Double click again to see more specific details about the conflict.
Here we see two columns: ‘Theirs’ and ’Mine.’ ‘Mine’ refers to the changes that you just made (in our example, ‘Mine’ would refer to Lisa’s changes). ‘Theirs’ would refer to the changes made by the other team member (Ryan). Our conflict is fairly trivial – the location of the start event in the Microflow changed. We can see the relative middle point was originally -100;200 (A), Ryan changed it to -220;200 (A’) and Lisa changed it to -95;195 (A’’).
There are two ways to resolve this conflict. To do either, right-click on the conflict within the Changes dock to get the following menu:
Here we see the two options – ‘Resolve conflict using mine’ and ‘Resolve conflict using theirs.’ If we select ‘Resolve conflict using mine,’ the changes that Ryan made (A’) will be ignored when this version is committed. If we select ‘Resolve conflict using theirs,’ the changes that Lisa made (A’’) will be removed, and Lisa’s document will become the same as Ryan’s A’.
These actions cannot be undone, so it is vital that you select carefully. If there is any uncertainty as to which to use, communicate with your team members. They will be able to help you decide which version is the best to keep.
What if I don’t know which to use?
What if Lisa doesn’t know what Ryan was trying to do? Or maybe Lisa needs some of Ryan’s changes, but also needs what she’s done? The two solutions provided may not be good enough.
If the conflicted item is anything other than the Domain Model, it can be duplicated. If the document can be duplicated, create a duplicate copy and append ‘_Conflict’ to the end. Then the conflict can be fixed using the ‘Resolve conflict using theirs’ option. Now Lisa has a copy of A’ and A’’! The two can then be viewed next to each other and Lisa can decide which pieces she wants to use.