Combining Changes and Conflict Resolution

Introduction

While working on your changes you may find that your local copy of the app model does not have all the changes that other team members have committed to the server (the Mendix Team Server, or an on-premises server). In Git terminology this is called being behind.

When this happens, Mendix Studio Pro offers two ways to combine your changes with changes from the server: Rebase and Merge commit.

Both options support the following features when it comes to resolving the conflicts:

• Fine-grained conflict resolution – When there are conflicting changes in a document, you do not have to choose between whole documents, resolving a conflict using your change or using their change. Instead, you can resolve conflicts at the level of individual elements, such as widgets, entities, attributes, or microflow actions. All non-conflicting changes from both sides are accepted automatically.
• No conflicts on changes to lists of widgets – When two developers make changes to widgets in the same document there is no conflict, the changes are combined. However, if the changes are made too close to the same place in the document, a list order conflict is reported that reminds the developer who is merging the changes to decide on the final order of the widgets in the list.
• They can be aborted at any time. Studio Pro will continue from your latest local commit.

The differences between the two approaches are as follows:

• Rebase (default):
  • Treats changes from the server as leading, by first retrieving the server state, and then reapplying your work to it.
  • Results in a simple commit history.
  • Resolves conflicts when reapplying your local commits. If you have three local commits, this could trigger conflict resolution three times.
• Merge commit:
  • Treats local and remote changes equally, and combines them in a separate merge commit.
  • Results in a more complicated commit history with extra merge commits.
  • Resolves conflicts once, regardless of the number of local and remote commits being merged.

Both processes are guided by notification controls showing the actual state and possible next steps.

Scenario

The clearest way to explain and illustrate the differences between Rebase and Merge commit when combining changes, is to examine an example scenario. The sections Rebase and Merge commit show how the two approaches work.

Starting Point

To start this scenario, let us assume that you have added the following entities to the domain model of your project:

• User
• Game

The User entity includes the string attributes E_mail and Second_E_mail.

Your Local Changes

During your work you make the following changes, each one in separate commit:

• Rename E_mail to Email.

  

• Rename Second_E_mail to Second_Email.

  

Another User’s Changes

In the meantime, your colleague also decided to make changes to both email fields. They have renamed E_mail to EmailAddress and removed Second_E_mail entirely. They have then pushed their changes to the server.

Summary

The current situation could be represented as shown below.

Combining Changes

This section outlines two possible approaches to the example scenario: Rebase and Merge commit.

Every time changes can be combined, for example when pulling changes from the server, you can choose the approach. You can change the default approach for your user account by adjusting the Preferences.

Rebase

Rebasing is the default way to integrate your work with the server changes. It moves your changes to the top of the changes from the server.

The following sections describe a possible rebase process for the example scenario.

Rebase Started

After starting the rebase, your two commits (#3 and #5) are temporarily put aside. Studio Pro shows the latest changes which were pulled from the server, including commits #2 and #4.

Resolving the First Conflict

Git tries to apply your first commit (#3) to the top of the rebasing branch (Mine). The commit will come after commit #4.

If there are no conflicts when comparing your commit (#3) with the latest state from the server (#4), Studio Pro automatically continues. A new commit is then created from your commit, shown as commit #3 in the image below. The process then continues with the next commit (#5).

In the example, however, there is a conflict because the E_mail attribute was renamed both on the server, and in your local work.

In the Changes pane, you can see your change in the Theirs column, and your colleague’s work in the Mine column.

You must resolve the conflict to proceed with the rebasing process. After resolving the conflict you can amend the current commit message. Commit #3 is then created.

Studio Pro can now continue with rebasing the next local commit (#5).

Resolving the Second Conflict

While rebasing the next commit (#5), another conflict is detected. You can choose to resolve this conflict by using either Theirs or Mine, or by reverting to the original.

You can also make additional changes which are added to the same commit. For example, you can add a Login attribute to the User entity. These changes are represented as Mine, together with changes that were taken from the server.

Once the conflict is resolved and you continue the rebase, a new commit (#5) is created from your commit (#5), and you can optionally amend the commit message.

As this was the last local commit to reapply, the rebasing can now be completed.

Testing Changes

Once the rebase process is completed, the original commits (#3 and #5) that were put aside are now removed. The final state of the branch has the commits #1, #2, #4, #3, and #5', while the server still only has commits #1, #2, and #4.

Your work is still on your local machine and you should test whether the combined state works as expected.

Pushing Changes

After testing the merged changes, push your work to the server to set the server state to the same as your local state.

Merge Commit

Merge commit is an alternative way to integrate your work with remote changes. The combined state is committed using a separate merge commit.

The following sections describe a possible merge commit process for the example scenario.

Merge Started

After starting the merge process, Studio Pro combines your local work (#3 and #5) with the state of the server (#2 and #4).

You must create a merge commit that merges commits #2 and #4 into your work. The changes already in your local work (#3 and #5) are kept.

Conflict Resolution: Resolving the Two Conflicts

If conflicts arise between any local and remote commits, you must resolve them before creating the merge commit for the combined state. Unlike rebasing, which requires conflict resolution for each local commit with conflicts, here you have only one round of conflict resolution.

Handling the Renaming of the E_mail attribute

As the E_mail attribute was renamed on both the server and in your local work, you must decide which changes to retain. Alternatively, you can make yet another change to the attribute. In the Changes pane, you can see your change in the Mine column, and your colleagues’ work in the Theirs column.

Handling the Removal of the Second_E_mail Attribute

Because your colleague removed the Second_E_mail attribute on the server, while you renamed it in your local work, there is another conflict which you must resolve.

You can also make additional changes which are added to the same commit. For example, you can add a Login attribute to the User entity.

After resolving all conflicts you can proceed with testing the app.

Testing and Pushing Changes

When the combined state is tested, you can commit the current state of the app. This is a new commit (#6), which always shows that it has merged commits #3 and #5.

By default Studio Pro also pushes your work to the server when making a commit.

Summary

You have merged your local work with the latest state from the server and resolved all conflicts. For rebasing this meant two rounds of conflict resolution, while for a merge commit you had a single round with all of the conflicts being resolved at the same time.

The history on the server now looks like this:

• After a rebase:

  

• After a merge commit:

  

Rebasing results in a simpler commit history, while a merge commit results in an additional commit that will always show as containing another commit or set of commits.

Resolving Conflicts

Studio Pro provides the following ways of resolving conflicts:

• Interactive merge
• Using whole documents

The following sections show how to resolve the conflicts when using merge commit. You can resolve conflicts during a rebase in the same way except that Mine and Theirs are reversed.

Using Interactive Merge

For the conflict, you can inspect the changes and decide which version to apply. Select the line that represents the conflict and choose Resolve using Mine or Resolve using Theirs.

The document updates immediately after you click the button. If you are not satisfied with your choice, you can use Undo to go back and try another option.

Instead of using Resolve using Mine or Resolve using Theirs, you can also resolve a conflict with the Mark as Resolved option. This means that you do not choose either side to resolve the conflict and keep things the way they were in the original. Neither of the new text changes are applied.

Once you have chosen one of the three options to resolve the conflict, green check marks appear to indicate that this conflict has been dealt with.

Once all conflicts have been resolved, click Accept and Exit to finalize the results. The document is saved and the conflict for that document is gone. The result is a document that contains changes from both sides and possibly some manual edits.

At any time, you can also choose to abort conflict resolution by clicking the Cancel button. The conflict will remain, and you can resolve it later.

Using Whole Documents

You can resolve conflicted documents too. There are two causes for document conflicts:

• One person deletes a document and the other makes a change inside that document.
• Both people move a document but to different places in the app tree.

The involved document is marked as conflicted and you can see the reason in the details column of the Changes pane. You can resolve the conflict by one choosing one of the following options:

• Using my whole document - while merging it will resolve all conflicts in this document using your work
• Using theirs whole document - while merging it will resolve all conflicts in this document using server changes

Notification Controls

While combining changes using either rebase or merge commit, you are shown a notification bar which displays the current status of the process and next available steps.

Shared Controls

The following controls are displayed for both rebases and merge commits.

Abort

The Abort button is visible for almost all steps. It indicates whether you are aborting a rebase or a merge commit.

Click and confirm this button to stop the combining process and undo all of the changes up to this point. In other words, the status is reset to the point before starting this process.

This has no effect on changes committed to the server, only your local work.

Show Conflicts

The Show conflicts button is only visible when there are conflicts in your application, for example conflicting changes to domain models or microflows.

Click this button to bring the Changes pane into the view, as this is the place where you can resolve this type of conflict.

Show File Conflicts

The Show file conflicts button is shown when there are conflicts in files which are not directly linked to your application.

When clicked, it opens up a pop-up window with a list of all the files that are affected by the update process, with conflicted ones at the top of the list.

You can also use the Show Changes on Disk menu item instead.

Rebase-Specific Controls

There are some buttons which are only shown when conflicts are found when doing a rebase.

Continue

The Continue button is visible when there are no more conflicts to resolve but there are still other changes to rebase. Click it to resume the rebase process.

Push

The Push button is visible after the rebase has finished successfully and your changes are ready to be pushed to the server. Click it to trigger a push operation.

Examples

Some examples of the rebase notification bar are shown below.

Conflict Detected

Rebase notification bar while there are still conflicts to be resolved.

Current Step Resolved

Rebase notification bar when conflicts for current step resolved.

Rebase Concluded

Rebase notification bar when whole rebase concluded.

Merge-Specific Controls

Commit

The Commit button is visible when there are no more conflicts to resolve, and the merge process is finished.

Click it to opens up the commit dialog with a predefined message indicating that this is a merge commit.

Examples

Some examples of the merge notification bar are shown below.

Conflicts Detected

Merge notification bar while in conflicts phase.

Merging Complete

Merge notification bar when merge is complete.