Resolve Merge Conflicts
Merge conflicts or code collisions sometimes occur as a normal part of the merge request workflow. However, they can be annoying for developers, especially when working on larger projects and in larger teams, where the chance of code collisions are increased. However, techniques exist to avoid encountering merge conflicts in the first place, and DataOps provides functionality for the online resolution of conflicts that do happen.
Avoiding Merge Conflicts
To reduce the chance of code conflicts affecting your merge requests, the following tips, techniques, and best practices are present and recommended in DataOps projects:
- Structure code in multiple, smaller files rather than large ones.
- Keep merge requests small and specific, minimizing code changes to a particular change.
- Merge as soon as possible, with regular review/approval cycles to avoid delays.
- Avoid non-standard code beautifiers that reformat whole files.
- Refresh your feature branch regularly if work spans multiple days.
- Ensure good communication within teams to better understand potential code overlaps.
Resolving Merge Conflicts in DataOps
When raising and reviewing merge requests in DataOps, developers and maintainers should see the following view - a safely-mergeable branch:
However, if there is a conflict in a file, usually caused by code changes that abut or overlap, the merge section looks like this:
The DataOps IDE provides a mechanism to click through, review the conflicting content, and resolve it to solve this merge conflict. Once the conflict has been resolved, the developer or maintainer can commit changes by clicking the Resolve conflicts button:
There can be more than one merge conflict in a feature branch.
The correct change(s) can be selected from this view and committed back to the source branch. The merge will then be able to go ahead successfully.
However, some changes, particularly involving the renaming or deletion of files, will not be resolvable in the DataOps platform:
In these scenarios, the developer should clone the project locally and rebase against the target branch, resolving any conflicts by hand. The developer can then push the updated branch back to the merge request, which should then become mergeable.
Resolving Merge Conflicts in Merge Requests
The intended workflow for merge requests is from a feature branch to a dev branch. As part of that workflow, you regularly need to resolve merge conflicts against the target branch before being able to perform the merge. The UI guides you through that process such that the conflict gets resolved in the feature branch.
Resolving merge conflicts in the Merge Request web interface reverses the commit direction you expect from a
git merge command. Changes will be applied to the source branch, where the source branch is the branch you are merging from.
Therefore, do NOT use the web interface to merge from a
dev branch to a feature branch if you have merge conflicts. Resolved merge conflicts would get committed to the
dev branch and not, as you might expect, the feature branch.
To resolve the merge conflicts use alternatives such as the Git command line
git merge or
git rebase, visual merge tools like Visual Studio Code, etc.