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.
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
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:
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
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.
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.