Problem
Sometimes when working on an Integration Services project with multiple developers, a merge conflict can occur in the git repository. In this tip, we’ll show you how to resolve this type of conflict and provide alternative options.
Solution
In part 1 of the tip, the basics of git branching are described, as well as some best practices for using git in Integration Services (SSIS) projects. In part 2, we demonstrated under what occasion a merge conflict can happen when merging two branches together. If you haven’t already, please read both parts before proceeding with this final part of the tip.
Resolve a Git Merge Conflict
When a merge conflict happens, the developer has a couple of choices:
- Resolve the conflict while merging the branch to the dev branch.
- First, pull the dev branch into the local branch to apply changes from other developers (which were already pushed to the dev branch). Then, the branch is merged to the dev branch (the conflicts should’ve already been resolved).
- Rebase the branch onto the dev branch. This means that all commits on the dev branch, since the branch was originally created, are applied to the branch (at the starting point). Then, all the commits of the local branch are applied. This resembles "cutting" the branch from the dev branch and "replanting" it on the dev branch at a later time.
Resolve While Merging
If the conflict is not too complex, it can be resolved directly in the pull request. In the Pull Request page in the browser, you can go to the conflicts tab to view the files that have a merge conflict. If you don’t see the conflicts tab, it’s possible you have to install the Pull Request Merge Conflict Extension from Microsoft DevLabs first.
When you select one of the files in conflict, you’ll get a preview of the conflict resolution at the right side of the screen. This is divided in three parts: on the left, the file from the source branch, on the right, from the destination branch, and at the bottom is the resulting file after conflict resolution.
Using the arrows in the top right, you can jump between different sections of the file that have a conflict. In the screenshot, you can see a conflict that was resolved automatically by git. On the left, the new package is missing. On the right, the package is indicated in blue. In the resulting file, the package "Package 1.dtsx" has been added to the file.
There’s a section git couldn’t resolve automatically and this is indicated in red.
In the result, both options are still present and they are surrounded with < and > to mark the start and end of the conflict. The names of the branches are also included. In most tools for resolving merge conflicts, you can easily choose if you want the left or the right option. However, this currently is not possible in the browser. You have to manually type in the bottom window to get the desired result. A possible solution could be this one:
Once the conflicts are resolved, you can hit "Submit Merge" at the top. If you’re sure you don’t need to actually merge, but rather just take the source or destination file, you can select these using the buttons at the top. For example, for the suo file we can take the target file:
Once the conflict is resolved, the pull request can be completed. The graph looks like this:
Resolve by Pulling the Dev Branch
Another option is to pull the dev branch into the feature/add-task branch. This will apply all commits from the dev branch which have happened after the add-task branch was created on this branch. The graph looks like this:
When the dev branch is pulled into the feature/add-task branch, a merge conflict will be detected. Once you resolve it, the resolution will be committed on the feature/add-task branch. When you create a new pull request to merge the branch into dev, there will be no conflict.
The advantage of this solution is that you can resolve the conflict on your own branch, not interfering with other people’s work on the dev branch. If something goes wrong during conflict resolution, only your branch has this problem and other developers are unaffected.
Resolve by Rebasing the Branch
When you "rebase" your current working branch on the dev branch, it’s like you are cutting your branch off and replanting it further down the timeline. For example:
Here, the feature/add-task branch is rebased on dev. This means the branch is re-created and the point in time is after the feature/add-package was merged into the dev branch (because that’s the latest commit on the dev branch). This means all commits on the dev branch are applied to the feature/add-task branch first (e.g. adding the new package). Then the actual commits of the branch are re-applied (adding a new-task). When this commit is applied, a merge conflict will be detected and you can resolve it in the branch itself. Once it is resolved, you can create a pull request and merge the branch back into the dev branch.
The difference between pulling the dev branch into your working branch or rebasing your working branch on dev, is the chronological order in which commits are applied.
- Pulling: first your own commits, then the commits of the dev branch.
- Rebasing: first the commits of the dev branch, then your own commits.
Although the end result is most likely the same from a code point of view, rebasing tends to be preferred as it keeps "branches clean". You can rebase in Visual Studio by right-clicking the branch and selecting "Rebase Onto…". Make sure you select the correct source and destination branch.
Conclusion
In this three-part tip, we saw how you can use branching in a git repository to work with multiple developers on the same SSIS project. Using branching, developers can work on different tasks without interfering with the work of others. One golden rule is to never work on the same object at the same time. If a conflict does occur, we’ve shown you how to resolve it.
Next Steps
- Other 3rd party tools offer a better interface for handling git repositories and especially for handling merge conflicts. There are free tools out there, such as Fork and SourceTree.
- If you haven’t already, read part 1 and part 2 of this tip.
- If you upgrade Visual Studio 2019 to the latest version, you might get a different look ‘n feel for the git user interface, depending on your preview settings.
- For more SSIS tips, check out this overview.
