Resolving Conflicts in a Pull Request

Scenario

This is a practical step-by-step guide on how to address conflicts that arise during the review of a pull request, emphasising effective communication and collaboration.

Step 1: Understanding the Conflict

When conflicts occur in a pull request, it means that the changes made in the branch being merged conflict with the existing codebase. To start resolving conflicts, it's crucial to understand the nature of the conflict. The pull request will provide details about the conflicting files and lines of code.

Step 2: Checking out the Branch Locally

To resolve conflicts effectively, we need to work with the conflicting code locally. Begin by cloning the repository if you haven't already and navigate to the repository's directory using the command line or a Git client. Ensure that you have the latest version of the main branch by running the following commands:

git checkout main
git pull origin main

Step 3: Checking out the Pull Request Branch

Next, check out the branch associated with the pull request that has conflicts. Execute the following command, replacing <branch-name> with the actual name of the branch:

git checkout <branch-name>

Step 4: Resolving Conflicts

Now that you're on the branch with conflicts, open the conflicting file(s) in your preferred code editor. The editor will display the conflict markers, typically consisting of <<<<<<<, =======, and >>>>>>>.

The conflicting sections will be surrounded by these markers, with the original code and the proposed changes visible. Manually edit the code to resolve the conflicts based on your understanding of the changes and the intended outcome.

Here's an example of how a conflict may appear:

<<<<<<< HEAD
def calculate_sum(a, b):
    return a + b
======= 
def calculate_product(a, b):
    return a * b
>>>>>>> feature-branch

In this example, the conflict arises because the function names and operations have been changed in both branches. Decide which version should be kept or modify the code to combine the desired changes.

Step 5: Resolving the Conflict Marks

After modifying the conflicting code, remove the conflict markers (<<<<<<<, =======, and >>>>>>>) to indicate that the conflict has been resolved. Review the code to ensure that the changes accurately reflect your intentions.

Step 6: Committing the Changes

Once you have resolved the conflicts in the file(s), save them and proceed to commit the changes. Use the following command to stage the modified files:

git add <file-name>

For multiple files, you can use the following command to stage all changes:

git add .

After staging the changes, commit them with a descriptive message:

git commit -m "Resolved conflicts in <file-name>"

Step 7: Pushing the Changes

Now that you have resolved the conflicts and committed the changes locally, it's time to push them to the remote repository. Use the following command to push the changes to the branch associated with the pull request:

git push origin <branch-name>

Step 8: Updating the Pull Request

With the conflicts resolved and the changes pushed to the remote repository, go to the pull request on the hosting platform (e.g., GitHub, Bitbucket) and refresh the page. The pull request will automatically update to reflect the changes made in the branch.

Step 9: Effective Communication and Collaboration

During the conflict resolution process, it is vital to maintain effective communication and collaboration with other team members involved in the pull request. Clearly document the changes made to resolve conflicts and provide context to reviewers.

Address any concerns or questions raised by reviewers promptly to ensure a smooth resolution.

Last updated