Merge conflicts are almost unavoidable when there are multiple people involved in the DevOps process. These can arise when two users are making changes to the same component or Apex class in different environments, and then push those changes to a shared environment where they ultimately overwrite each other. This can result in undetected changes to components and hours of re-work, delaying project completion.

Of course, the best way to manage these conflicts is to "shift left" by using an ALM tool (such as Jira) and ensure that the problem is avoided from the start through careful planning and assignment of tasks, however that's easier said than done. Typically, if merge conflicts are still encountered, the next option is to use version control and assign a release manager to monitor pull requests, which can be facilitated through Copado's Deployments with Pull Requests method. But what if you're not familiar with how to use a pull request? For instances where merge conflicts are still encountered, Work Items with Copado Essentials+ offers you the ability to help detect those conflicts from within the Essentials interface before they're overwritten, even without the use of a Git repository.

Note: This feature is available for activation for Copado Essentials plus license holders. Contact your Team Owner or Team Lead to have it turned on.

Using Copado Essentials+, potential merge conflicts are now detected within a Work Item when two users are pushing changes for the same component to a shared environment. When this potential conflict is detected, Copado Essentials+ will highlight the affected component in yellow, offering you the ability to resolve the conflict directly from within our application.

To resolve a merge conflict, click the blue "Resolve" button on the affected component. This action will open a three-paned view that will enable you to review the conflicted component as it exists in the source (right) and target (left) environments, as well as build out a resolution in the center pane that will then be deployed to the target environment. As seen in the image below, this resolution can be built out using the arrows that are highlighted to move specific lines between environments.

Following a review of each version of the component in question, a potential resolution can be seen below, where pieces of each component have been incorporated into the center pane. When you are satisfied with the resolution, click "Continue" to move to the in-line text editor for any final updates.

On this screen, the resolutions made can be seen highlighted in yellow, and you are now able to make any final adjustments to the component using the in-line text editor. This can be helpful when neither component contains exactly what you need, but a quick tweak is all that is required. After any final adjustments are made, click Save.

The resolved component is now ready to be deployed to the target environment, and the resolution can be reviewed by clicking into the blue "View resolved" button. As part of a Work Item, this deployment can also be committed simultaneously to your Git repository, if one has been setup, as recommended in our Best Practices.

Merge conflicts can be a complicated issue, but the solution doesn't have to be. With Work Items, we aim to make the DevOps process streamlined and approachable, giving you the ability to quickly deploy from Development environments to Production, manage merge conflicts, incorporate robust robotic testing, and committing to Git along the way. If you're interested in finding out more about how to use Work Items, check out this article.