Git for Beginners - Part 7 - Git Merging and Merge Conflicts

In this tutorial, I will cover about Git Merging and Merge Conflicts. In the last tutorial, we learnt about Git branching. Basically, Git merging is the opposite of Git branching, but it has additional features.

Merging combines the changes from both to form the current branch. And also it gathers all the commits you have done for particular branches. You can keep working on merged branches if are not deleted. Because when you merge some branch, it is not deleted.

      Let's consider the merging of two branches, in this case, MyBranch will be merged to the master branch.

you will notice that the file1 is changed because of the merge. When you check the file1 the phrase,  'changed the file1 on MyBranch' can be seen in the master branch although I have done it in MyBranch.

If you check your Git log, all of the commits, done in both the MyBranch and the master branch are now can be seen. Because the commits are also have been merged. 

Merge Conflict:

        Above we have focused on Git Merging and will look in deeper about Merge Conflicts. Generally, merge conflicts happen when you changes the same line or the same area of a file. Most of the Version Control Systems provide the option of merging and leave the responsibility of resolving merge conflicts to the user. Most of the times Git tries to resolve merge conflicts. But it may ask you to resolve the issue when it cannot determine which bunch of code to choose. 

Once there is a merge conflict, you must resolve it manually. Otherwise, you cannot switch to another branch.

Let's consider an example. In this case, I will change the file2 which leads to a merge conflict.

In master branch, 

In MyBranch,

Once you have changed the same file on different branches, remember to commit changes for both branches.

Now try to merge the file on the master branch. But you will notice that auto merging is failed by noticing the merge conflict. The reason is Git cannot resolve what is right in that line. Go ahead and check your file, in this case, file2.

What you can observe is there are <<<<<<<, >>>>>>> and ======= markers. These are called conflict markers. These markers are created by Git. The <<<<<<< and >>>>>>>> signs indicate the conflicted area in yuor code and ======= sign separate the two versions. The HEAD means the latest commit. The bottum version is the other branch.

This is your time to what is correct and what is wrong. Go ahead and remove the unwanted parts of your code and resolve the problem. 

In this case, both chocolate and pizza are awesome ;-). Therefore I will keep both of them. 

When you check the Git log, you will notice that all commits that you have done are sitting here.



This is somewhat difficult to do it. But now you are ensured by yourself that the final source code is pretty accurate. Once you resolve the merge conflict, go ahead and switch to your branch, in this case, to the MyBranch. (Now you can switch to any branch). You will notice that nothing is changed in file2. Therefore you can continue work on with branch independently.