There are multiple answers on how to resolve merge conflicts in Git in different scenarios. And the answers differ based on the components and the scenario. It also depends on the method we are implementing. But there is a common way of solving things.
1. Conflicts Resulting from GitHub Pull Requests
I purposefully created a merge conflict with two separate feature branches in this scenario. Both feature branches branched off from the same master branch but were merged back into it at different times via pull requests. The pull request that was merged first, as you might expect, had no issues. When I attempted to merge the second pull request, however, I encountered a merge conflict.
When you have a merge conflict, you should expect to see something like the image below in the pull request.
The merge pull request button has been disabled on GitHub. A notification about disputes in the branch is also included.
At this point, there are two possibilities:
- The button to resolve conflicts is available.
- The button to resolve disagreements is not present.
I’ll go ahead and assume the first situation of git resolved the merge conflict. The second has the same solution as when you have a merge conflict when fetching remote changes locally. In that case, the resolution must be carried out locally first.
Resolve in the Web Editor on GitHub
- When you click Resolve Conflicts, the whole display of the altered files in the pull request should be shown. The Mark as the resolved button has been disabled on GitHub.
- In the first file, you see, resolve the conflicts.
- Ensure that all evidence of, >>>>>>, <<<<<<<<<< and =======
- If you’ve done everything correctly, the Mark as resolved button should appear for that particular file.
- Select the next file to resolve if there are many files with conflicts. Repeat steps two through four until all merge conflicts in your pull requests have been resolved.
- The Merge Commit button is now available.
- Continue with your merge pull request by clicking Commit merge.
2. Pulling Remote Changes to a Local Repository Causes Conflicts
It’s only fair that you learn how to resolve merge conflicts when fetching remote changes from GitHub, given that you know how to manage merge conflicts when sending pull requests to GitHub. As mentioned in the first section, this section will also address dealing with more intricate merge conflicts that GitHub does not allow you to resolve.
Let’s get this started:
- Switch to <branch-to-merge-into> and fetch all the remote modifications from GitHub. Assume the same method as the last section and attempt to merge feature/add-section2 into master. As a result, <branch-to-merge-into> is the master.
- git fetch origin
- git checkout <branch-to-merge-into>
- git pull
- Git merges feature/add-section2 causes a merge conflict.
- You now have essentially two options for resolving your conflict:
- You can go through the conflicts one by one in your favorite IDE or code editor. Some editors may even assist you by marking the files themselves.
- You can use your system’s built-in merge tools (I will cover this in the next section).
- By eliminating the >>>> and then modifying the code for all affected files, you’re essentially accomplishing the same thing as with the GitHub web editor example.
- When you type git status, you’ll get a message regarding unmerged paths.
- A commit message about merging conflicts will appear if you type git commit -a.
- You may either add more comments or leave it as it is. You’re done once you’ve staged the change.
If you’re using a Mac, you have a variety of merge tools to choose from. Meld, open diff, vimdiff, and tortoiseidiff are a few examples.
Simply type git merge tool once you’ve generated a local merge conflict to activate these tools. You have the option of configuring your merge tool. When you type “git config merge.tool vimdiff,” vimdiff will be set as the merge tool of choice. If you like, you can also install alternative merge tools.
Finally, type git merge tool again to start the merge tool. Here’s a screenshot of the merge tool that I use. Open diff is responsible for triggering FileMerge, which I prefer.
3. Conflicts Occurring as a result of a Merge and Rebase
You might want to merge and rebase simultaneously, but a merge conflict will prevent you from doing so. You may be able to complete the usual merging on your own, but it’s also possible that you won’t. But let’s say you insist on using the rebase method. So, what exactly do you do?
The feature/add-section2 branch is being merged and rebased into the master branch once more.
- For your branch-to-merge-into,> and feature-branch>, fetch all the remote updates from GitHub. Remember that your feature branch is feature/add-section2 in this example.
- git fetch origin
- git checkout master
- git pull
- git checkout feature/add-section2
- git pull
- git pull origin master -rebase git pull origin master -rebase git pull origin master -rebase git pull origin master -rebase git pull origin master -rebase git
- As usual, resolve the merge conflict.
- git push -u origin feature/add-section2 -f git push -u origin feature/add-section2 -f git push -u origin feature/add-section2 -f git push -u origin feature/add-section2 -f (Warning! Make sure that no one else has made any new changes to your feature branch’s remote version. The forced push will override those new changes.)
- You can now execute the merging and rebase on GitHub.
These are three scenarios of git resolve merge conflict.
How Can Merge Conflicts Be Reduced?
So far, I’ve discussed numerous approaches to resolving merge disputes in three scenarios:
Changes at a Distance Frequently to avoid major conflicts. Fetch remote changes from the main branches regularly and handle them upstream. While you may have to deal with merge conflicts more frequently, you’ll be dealing with fewer conflicts each time. Merge disputes may be a pain to resolve, especially for large projects involving dozens of collaborators and a codebase with millions of lines.
Reduce the number of developers working on the same branch
When multiple people work on different features and merge back to the same branch, merge conflicts become far more common. Your project manager can assist you here. They will most likely plan to release branches from the master branch, then subdivide the release branches into smaller feature branches, which can subsequently be subdivided further. I believe in the old divide and conquer strategy.
With trunk-based development, implement a feature flags management solution.
Using feature flags instead of several feature branches may be a more straightforward solution. Use a feature flag management system that enables trunk-based development. This is especially important at the early stages of development when features are frequently abandoned or radically altered in response to criticism. It’s worth having a cleaner technique to reduce merge conflicts for your productivity and developer sanity.
This is all about the git resolve merge conflicts. I hope you understood things and got knowledge on this topic.