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:
1.
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
2.
Git merges feature/add-section2 causes a merge conflict.
3.
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).
4.
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.
5.
When you type git status, you’ll get a message regarding unmerged paths.
6.
A commit message about merging conflicts will appear if you type git commit -a.
7.
You may either add more comments or leave it as it is. You’re done once you’ve
staged the change.
Configuring Mergetools
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.
1. 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
2.
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
3.
As usual, resolve the merge conflict.
4.
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.)
5.
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.
