In the previous post, we created a branch called bug_fix_#001 and learned to make this our current branch using the git checkout <branch name> command. Once on this branch we made a change to one of our files (simulating a bug fix) and committed the change.

By looking at the content of the changed file and our Git log, we realized that by switching branches we were truly switching universes. Our master branch did not have any record of these changes. This is the beauty of Git: you can work on files on a branch and you don’t mess up your current working version of these files on the master branch. Once you have fixed the issue with your program or reworked the discussion of your upcoming paper, you can seamlessly incorporate these changes into your master branch.

Verifying differences between branches

It is always a good idea to verify the changes you will be bringing into our master branch before merging two branches. This can be done with the git diff or git diffc commands. Here is an example:

06:28 ~/.../project_repo$ git diff master ..bug_fix_#001
diff --git a/doc1_new.txt b/doc1_new.txt
index 10d2db2..fafa9be 100644
--- a/doc1_new.txt
+++ b/doc1_new.txt
@@ -3,3 +3,4 @@ Line 3 of document 1.
 Line 4 of document 1.
 Line 5 of document 1.
 Line 6 of document 1.
+Line 7, doc 1. Branch bug_fix_#001 project_repo.

The output of git diff master ..bug_fix_#001 shows us that the version of doc1_new.txt that resides on our bug_fix_#001 has a new line. If we were interest in word-level changes, we could have used git diffc.

Merging changes into the master branch

Great, we know the changes that will be included when we merge our bug_fix_#001 branch into our master branch. The first thing we need to do is make sure we are located on the master branch. If you are still located on the bug_fix_#001 branch, change to the master branch before moving on (verifying your current branch and changing between branches was introduced in the previous post).

Now we are ready to merge the changes into our master branch:

06:28 ~/.../project_repo$ git merge bug_fix_#001
Updating bde15d4..a81aa62
Fast-forward
 doc1_new.txt | 1 +
 1 file changed, 1 insertion(+)

Simple as that! The new line that was added on our bug_fix_#001 branch has been added to the version of doc1_new.txt on our master branch. The output from Git tells us the update was carried out as a Fast-forward. Don’t worry too much about what this means right now, it will make more sense when we go through additional examples of merging branches. A hint to what Fast-forward is can be gleened by looking at your Git log. Go ahead, run git slog. Do you see any evidence that the most recent commit comes from the bug_fix_#001 branch?

Summary

That was a simple example of working with Git branches. When working on a branch, you can make changes to files without worrying that your most recent working version (located on the master branch) will be effected. Only when you are sure the bug fix is correct and does not mess up your working version do you incorporate the changes into your main project located on the master branch. In our next lesson, we will learn to remove unwanted branches and introduce a new example using branches.