How To Merge Git branch To Master And Handle Merge Conflicts

In the previous article, we’ve gone through basic of Git Branching commands. And figured out how to create new branches and work effectively with them. Of course, we’ve mentioned how to merge branch back to master branch but there are certainly some key points to add.

For the beginning let say a few words about what a Git branch merge is.

Essential, it is a way Git putting a forked branch history back together. It allows us to unite created before parallel lines of development into main development line. As a result, the main line will be refreshed to reflect merging.

First, we have to ensure that all remote changes are updated with branches that going be merged. For this we run git fetch to pull latest remote commits, after that run git pull at master branch, to verify it has the latest updates.

Also, before merging we should use git command – git checkout, to choose the main branch to which we want to merge other branches. And just keep in mind that merging always performs on that branch TO which will merge, other words – on receiving branch.

There are two ways Git performs merging and it defines the merge algorithm automatically. But we suppose that you should better know about them. Because you know, forewarned is forearmed.

Fast Forward Merge

Say we are working on a website and already made some commits. At some point, we have an urgent task to add a new feature. So we create a new branch, make appropriate commits and when everything is done we move to merge, and eventually remove a new feature branch. This example is shown in the code below.


# Start a new feature
git checkout -b <new-feature file> master
# Edit some files
git add <new-feature file>
git commit -m "new-feature beginning"
# Edit some files
git add <file>
git commit -m "new-feature finish"
# Merge in the new-feature branch
git checkout master
git merge <new-feature>
git branch -d <new-feature>

In such case, Git automatically used Fast Forward Merge. To visualize it, look at pictures below.
fast forward merge

A fast-forward merge occurs here because while we were adding a new feature, the master branch remained the same and haven’t had any new commits. It means that main branch tip wasn’t moved. So there is a linear path from <new-feature> branch tip to the <master> branch tip. And thanks to that Git uses “fast forward” method to move one branch tip up to another and nicely integrate its histories.

3-way merge

But let imagine a bit different situation. We actually created a new branch, <new-feature>, but in meanwhile we got another call to fix a bug. So we left for a while our work on the new feature. Check out to master branch and create another <bug fixing> branch. Work on it, make some commits and merge it to the master branch.


# Start <new-feature>
git checkout -b <new-feature> master
# Edit some files
git add <new-feature file>
git commit -m <the new-feature begining>
# Return to master branch
git checkout master
# Create Bug fixing branch
git create - b <bug fixing> master
# Edit some files
git add <bug fixing file>
git commit -m <successful bug fixing>
# Merge in <bug fixing> branch
git checkout master
git merge <bug fixing>
git -d <bug fixing>
#Finish work on the new-feature
git checkout <new-feature>
git commit -m <the new-feature finish>
# Merge in branch
git checkout master
git merge <new-feature>

And only after all that we return to our <new-feature> branch. And while <bug fixing> branch was merged by the fast forward algorithm, the <new-feature> branch can’t be merged the same way. Because <master> branch tip was already moved forward by the previous merging. For such cases, Git uses a 3-way-merge.

For clarity see images below. They accurately demonstrate the process described above.

3 way merge step1

3 way merge step2

3 way merge step3

3 way merge step4

The last scheme illustrates how Git unites all the changes of each queued merge commit sequence. For this, it takes two branch tips, finds a common base commit, and then creates a new “merge commit”.

Conflict

In three-way merging, there may occur a conflict situation.

Note that it can only occur in 3-way merging.

It will happen when we’ll ask Git to merge branches on which we’ve made changes at the same part of the same file differently. So Git simply will be confused which version it should use.

Let’s take it back to our example. If we have changed on both <new-feature> and <bug fixing> branch the same part of the same  file, we’ll get a conflict message from Git that will look smth like this:


git merge <new-feature>
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed;
fix conflicts and then commit the result.

In such case, Git will pause merging and allow us to resolve occurred conflict manually.

To see what exactly we need to resolve run git status command.

And assuming the conflict occurred in the section of index.html we’ll see smth like this:

On branch master 
Unmerged paths: 
(use "git add/rm ..." as appropriate to mark resolution) 
both modified: index.html

Git will show us conflict-affected files by marking the conflicted content that needs to be resolved.

Those indicators are <<<<<<<, =======, and >>>>>>>.

<<<<<<< master:index.html

<div id="contact form">contact : [email protected]</div>

=======

<div id="footer">

 please contact us at [email protected]

</div>

>>>>>>> new-feature:index.html

Where, under the  <<<<<<< master line shown

conflicted text from master

=======

conflicted text from new-feature branch

>>>>>>> new-feature branch

content before the ======= marker is the receiving branch and the part after is the merging branch.

After a conflict resolved, we should tell Git that everything is fine now. For this, we run git add command. And eventually, finish the merge. For this, we simply need to commit a usual snapshot.

So, just to sum things up. Git merging:

  • can be performed in two ways: Fast Forward and 3-way merging:
  • unites line of commits into one unified history of commits;
  • and may face a conflict in case of different changes made at the same place in the one file in both commit lines.
  • gpu logic

    PLEASE INCLUDE THE OUTPUT of actual commands. Teaching git to new users is important because of it's power. Please replace the word issue and words issue fix and fix issue also "fix issue tip". In most English speaking countries issue means "a version" or "to give" or "to release" in English. That being ambiguous already, you mean something else again which is even more baffling to read. For example: "I have issues about your issue words, so issue you with an issue statement about my issue of your git issue tutorial document issued in American that is not English." Makes sense? NOT! We have to read the tutorial about 3 times to get the idea and that is obviously irritating as it is without example output. It does not scan because of the dictionary and colloquial English is not American English. Foo and bar is another annoying example. Use a real project name perhaps? Add extra git commands to list branches: git branch -a; git status; and list the output. PLEASE INCLUDE THE OUTPUT.

    • admin

      Hello gpu logic! Thank you for pointing out our mistakes! Sorry for the misunderstanding with words, we have made changes for a better understanding. Considering adding extra git commands and the output, we will add it to the article in a few days.