Development environment version control is the practice of tracking and managing changes to software code. This is important because if changes are made in different sections of the file tree simultaneously, then conflicts and bugs are at risk of being made.
The conflict we explore in this blog is a "merge conflict". Specifically, when competing changes have been made.
Development Environment Version Control - Merge Conflicts, Root Cause And Resolution
The Possible Merge Conflict Scenario:
The Master Branch continuously updates to the latest code, identical to the Production Code Base.
After each release, the Release Manager refreshes the Development Branch by raising a pull request from the Master Branch to the Development Branch to keep the code base in sync with the Production Code Base.
There are two parallel development tracks: Track 1 (HotFix) and Track 2.
Each track handles two mostly independent modules, and both tracks are part of the same sprint.
The Release Manager created these two branches (FeatureBranch1 & FeatureBranch2) at the start of the sprint from the Development Branch.
Developer 1 & Developer 2 are working on Track 1 & Track 2, respectively.
Developer 1 completed the development of Track 1 and was successfully able to pull & merge the developed code from FeatureBranch1 to Development Branch.
Next, Developer 2, after completion of Track 2, tries to merge their changes to the Development Branch through a pull request from FeatureBranch2. Here the Merge Conflict happens.
Files In The Repository At A Glance:
The Root Cause:
Both tracks used a common file (in this case, CodeFile.txt).
The starting code pulled from the Development Branch for Track 1 and Track 2 had the same version of the Class A file.
Before they merge the files from Track 2, the pull cannot be executed from the development branch due to development & time complexities. Thus, the delta change was not being tracked in the Header file of Track 2, giving rise to merge conflict errors, i.e.
The version of the file class at the start was "Track 1 & 2" the initial version was V1, which was tracked in the header of each Feature Branch, which is important for successive version updates to the class.
Each updated the version of the Class A to version V2.
After the merge of FeatureBranch1 of Track 1, the version of Class A in the Development Branch is V2.
Thus, when FeatureBranch2 of Track 2 tried to merge it, it encountered the same file version in the destination with differences in the code at the same sections.
Common approach observed:
Take the backup of their files and restore the initial version of the branch.
Pull the Development Branch in their feature branch.
Compare their version of the file and the available file in the updated feature branch in diff-checkers.
Make the necessary changes to add their code to resolve the conflicts for the fresh pull.
Once you receive the Merge Conflict, click either “web editor” or “Resolve Conflicts”.
This will open the conflicted file online to edit and resolve the conflict.
The section between “<<<<<<<” & “=======” – identifies the portion to be added as part of the pull request.
The section between "=======" & ">>>>>>" – identified the portion which was already present in the branch at the same line number in the original file.
The developer can review it themselves (or sit with the Release Manager & Tech Lead) to resolve the conflict on the fly.
After review, the Developer/Team can update the file, remove the identifiers and click Mark as resolved.
After the conflict is resolved, the system will ask to merge these changes through a commit to update FeatureBranch2 with the latest file version.
Once the file version in the FeatureBranch2 is updated, the system will allow seamless Pull request merging.
If you’d like to understand more about how we can support and enable your Salesforce journey, get in touch at email@example.com or fill out a contact form!