In the previous two installments (part one is here, followed by part two), we mentioned the concept of merging branches in Git. Let’s go into merging in more detail.

When you perform a merge, you effectively merge one branch into another—typically a feature branch or bug fix branch into a main branch such as master or develop. Not only will the code changes get merged in, but also all the commits that went into the feature branch. This is an important concept to remember, because what it effectively means is all your history and work stays intact. In fact, because of that, you can often delete the feature branch after it’s been merged into the main branch while still maintaining a full log of what you did.

Because merging is such a fundamental part of your daily Git work, I’m going to give a bit of extra detail about how it works.

Git Scenario

If you use Git on a regular basis, you will end up merging branches frequently. You may be merging your own branches, or you may merge branches from multiple programmers into a single branch. 

Most of the time, merging goes smoothly. It’s a simple process of starting with a main branch, such a branch you might call develop, which does not change while you’re working on your feature branch. If all goes well, the changes will easily slip into place. However, at times you might encounter problems where the branches are too different, and Git can’t automatically merge them.

In either case, you start the same way. Suppose you have a branch called newlogin that contains new features for logging into a site. You had created this branch by starting with, for example, the develop branch. To do that, you had checked out develop like so:

git checkout develop

And then started a new branch from that point called newlogin:

git checkout -b newlogin

Then you preceded to make changes, building the new feature. Now you’re done and you want to merge those features back into the develop branch. To do the merge, you want to be in the branch that is receiving the other branch (in this case, develop). Check which branch you’re in by typing:

git status

The first line of the output will tell you which branch you’re on, such as:

On branch develop

If you’re not on the receiving branch, then switch to it by typing:

git checkout develop

Ready to Merge

Now you’re ready to merge. Simply type:

git merge newlogin

The last parameter is the name of the branch you’re merging in (in this case, newlogin). Remember: You’re in the branch receiving the merge, and in the merge command you type the name of the branch you’re merging in. If all goes well, you’ll see a somewhat cryptic response:

Updating 0f288f0..d0a6bdb
Fast-forward
 test1.txt | 1 +
 1 file changed, 1 insertion(+)

The hex numbers at the start are the first few digits of the commits (each commit gets a long, unique hexadecimal number).

If you had made changes to newlogin—which began its life based on develop—and meanwhile nobody made any changes to develop, the merge will be a simple merge, and Git will easily copy the history over from newlogin to develop. However, if somebody made changes to files in develop, and in particular a file that you also worked on in newlogin, you’re going to encounter a merge conflict. 

Git won’t know how to merge because there are two newer copies of the file. When you try to merge, Git will suspend the merge process with a message like this:

Auto-merging test1.txt
CONFLICT (content): Merge conflict in test1.txt
Automatic merge failed; fix conflicts and then commit the result.

If you open up the file test1.txt, you’ll see that it will contain lines from both branches, with several greater-than and less-than symbols highlighting the differences, like so:

<<<<<<< HEAD
bbb
=======
aaa
>>>>>>> newlogin

To fix this, you have to open the file in your editor and modify the text or code so it’s how you want it to look in the final merged copy. Oftentimes, this will mean choosing one set of text over the other. Also, if you run Git status, you’ll see a message that you have unmerged paths. Git knows you’re in the middle of a merge. Make the changes to the file, then do a Git add and a Git commit:

git add test1.txt
git commit -a -m ‘Description’

Then finally do the merge again and it will work.

git merge 

Conclusion

With Git, merging is typically a regular experience, often happening multiple times a day. What we’ve discussed here is usually enough to get by with merging. However, after you’ve taken some time and have become comfortable with merging, I recommend that you read the official documentation on merging so you can get a full understanding of it. You can find it here. Also, there is an excellent reference guide here.