GIT: Merging the Branches

You might have already guessed what is in store for us ahead. In the last chapter we created a few branches to help us organize our work. We created branches with the hope that someday they would help the tree grow into its final form. Let's continue our example from last chapter.

Recall that we created two new branches, signin_feature and subs_feature, out of with the latter was deleted as it was no longer needed. As of now, we just have two branches, but in a larger project you may have hundreds or even thousands of branches. So your project might look like it has a lot of parallel branches. The final goal would be to combine all of these branches into one final copy. You may consider merging as the opposite of branching.

Merging combines the changes from both branches to form one cohesive branch. It also combines all the commits from the branches. The branch being merged isn't deleted, it's still available and you can keep working on it even after you've merged it.

But what do we do with files that were changed in both the branches. How can we decide which version do we wish to carry forward to the final project? Such a situation is known as a merge-conflict. While most VCS provide the option of merging, they leave the responsibility of resolving the merge conflict into your hands. Not very smart. This is another area where Git is better than most VCS.

Git is pretty smart about resolving merge conflicts and tries to resolve them automatically most of the times. It may ask you to resolve the issue when it cannot determine which file to choose, let's discuss that a bit later. In this chapter, we'll see how Git works around merging and automatically resolves merge conflicts.

So let's say we've been working on the signin_feature and you finally feel the need to commit it and add it to the main project, i.e. the master branch. We haven't changed anything yet so there is no possibility of a merge conflict. Let's go ahead and merge the signin branch to our master branch. In such cases, merging is a quick and painless command. Run a quick status command to know which branch you are on. We want to be on the master branch, so switch to master if you already haven't done so.

Go ahead and run $ git log to see what the commit history looks like on master and run the following to merge the branch 'signin_feature' to master.

$ git merge signin_feature

Run the $ git log command and check for changes. Sure enough, our commit histories have now been merged. This was pretty easy, since there were no conflicts to resolve.

Let's go ahead and set up a conflict for Git to resolve. Open up the README file and change the first line. commit this change to master and checkout the signin_feature branch.

Change the content of the README again. This time on a different line. Commit it and checkout the master branch. Run the merge command just like before.

The output is different this time. Git tells us that it is automerging README. It has successfully detected that the file was changed in both branches. But because they were on different lines, Git was able to merge them. Running $ git log gives us a new commit message this time, too!

Merge branch 'signin_feature'

The branch signin_feature is still available. The log for this branch shows nothing has been changed at all. It only affected the master branch. So that was easy and smart from Git. But what about the times Git cannot decide what to do? Does hell break lose? Let's find out in the next chapter...