Resolving a Merge Conflict in a Pull Request

1. What is a Merge Conflict in a Pull Request?

A merge conflict occurs when Git cannot automatically combine changes from the Pull Request's source branch with the target branch.

For example:

Source branch : feature/login
Target branch : main

Suppose both branches changed the same lines of the same file differently.

main
  |
  A---B---C
       \
        D---E   feature/login

If commit C changed a line that was also changed differently in D or E, Git may not know which version should be kept.

The Pull Request may then show:

This branch has conflicts that must be resolved.

The conflict must be resolved before the PR can be merged.

2. Simple Commands

A common and safe approach is to bring the latest main into your feature branch.

git switch main
git pull origin main

git switch feature/login
git merge main

If conflicts occur, resolve them in the affected files.

Then:

git add .
git commit -m "Resolve merge conflicts"
git push origin feature/login

The existing Pull Request is automatically updated.

3. Detailed Explanation

Assume you already created this PR:

feature/login  --->  main

Meanwhile, another developer has merged changes into main.

Now the history might look like:

             D---E   feature/login
            /
A---B------C---F---G   main

Your feature branch and main have both moved forward.

If they modified overlapping code differently, the PR can have conflicts.

Step 1: Get the latest main

Switch to main:

git switch main

Download and integrate the latest remote changes:

git pull origin main

Now your local main matches the latest remote main.

Step 2: Switch back to your feature branch

git switch feature/login

Step 3: Merge main into the feature branch

git merge main

If there is no conflict, Git completes the merge automatically.

If there is a conflict, you may see:

CONFLICT (content): Merge conflict in LoginService.cs
Automatic merge failed; fix conflicts and then commit the result.

Check the conflicted files:

git status

4. Understand the Conflict Markers

Git places conflict markers in the affected file.

For example:

<<<<<<< HEAD
return "Login successful";
=======
return "User login successful";
>>>>>>> main

The sections mean:

<<<<<<< HEAD

Your current feature branch code

=======

Incoming code from main

>>>>>>> main

Git is essentially asking:

Which version should I keep, or should I combine them?

5. Resolve the Conflict Manually

Suppose you decide the correct final code should be:

return "User login successful";

Remove all the Git conflict markers:

<<<<<<<
=======
>>>>>>>

The final file should contain only valid code:

return "User login successful";

Sometimes the correct solution is not simply choosing one side. You may need to combine both changes.

For example:

ValidateUser(user);

LogLogin(user);

return "Login successful";

This is why developers should understand the code before resolving a conflict.

6. Mark the Conflict as Resolved

After fixing the files:

git add LoginService.cs

Or, if several files were resolved:

git add .

Check:

git status

Then commit:

git commit -m "Resolve merge conflicts with main"

7. Push the Resolved Branch

git push origin feature/login

You do not normally need to create a new Pull Request.

The existing PR points to feature/login, so when you push new commits to that branch, GitHub or Azure DevOps updates the PR automatically.

The flow is:

PR has conflict
      |
      v
Get latest main
      |
      v
Merge main into feature/login
      |
      v
Resolve conflicting files
      |
      v
git add
      |
      v
git commit
      |
      v
git push
      |
      v
Existing PR updated
      |
      v
CI / Review
      |
      v
Merge PR

8. Alternative: Resolve Through GitHub / Azure DevOps UI

For relatively simple conflicts, GitHub or Azure DevOps may provide a web-based conflict-resolution interface.

Typical process:

Pull Request
     ↓
Resolve Conflicts
     ↓
Edit conflicting code
     ↓
Mark as Resolved
     ↓
Commit
     ↓
PR updated

For complex conflicts, resolving them locally is generally preferable because you can:

• Compile the application
• Run unit tests
• Debug the code
• Use IDE merge tools
• Review the complete changes

For example, Visual Studio provides a graphical merge-conflict editor.

9. Merge vs Rebase Approach

Another approach is to rebase the feature branch onto the latest main:

git switch feature/login
git fetch origin
git rebase origin/main

Resolve conflicts, then:

git add LoginService.cs
git rebase --continue

After a rebase, the commit history has been rewritten, so updating an already-pushed feature branch may require:

git push --force-with-lease

Important Warning

Avoid casually rebasing a branch shared by several developers because rebase rewrites commit history.

For interview purposes, a straightforward team-friendly answer is usually:

git switch main
git pull origin main

git switch feature/login
git merge main

# resolve conflicts

git add .
git commit -m "Resolve merge conflicts"
git push

10. Merge vs Rebase for PR Conflicts

If your team has an established branching policy, follow that policy rather than choosing merge or rebase individually.

11. Key Points

• A PR conflict occurs when Git cannot automatically merge the source and target branches.
• First get the latest target branch, such as main.
• Merge main into your feature branch and resolve the conflicting files.
• Conflict markers are:

<<<<<<< HEAD
=======
>>>>>>> main

• Remove the markers and keep the correct final code.
• Use git add to mark files as resolved.
• Commit and push the resolution.
• The existing Pull Request updates automatically after the push.
• Run builds and tests after resolving conflicts because a syntactically resolved conflict can still introduce logical bugs.
• Complex conflicts are usually easier to resolve locally using Visual Studio or another merge tool.
• rebase can also resolve the situation, but it rewrites history and should be used carefully on shared branches.
• If a rebased branch must be force-pushed, prefer git push --force-with-lease over git push --force.

12. Interview Answer

If a Pull Request has a merge conflict, I first update the target branch, such as main, locally. Then I switch to my feature branch and merge the latest main into it. Git identifies the conflicting files, and I manually resolve the conflict markers by deciding the correct final code. After resolving the conflicts, I use git add, commit the resolution, run the necessary build and tests, and push the feature branch. The existing Pull Request is automatically updated, and once the conflicts and required checks are cleared, the PR can be reviewed and merged.