Git lesson 7 : creating and working with branches
In the previous post you learned about Git branches. Specifically, you learned about how branches could be used to make changes or additions to files in secret. The original versions of the files that are presentable (manuscripts, thesis, etc) or functional (computer programs) remain available as you make your changes on a branch. The beauty of this approach is that you are free to experiment as much as you like with your documents and programs on a branch; only when you are satisfied with the new version of your documents do you include (or merge) these changes into your primary (or master) branch.
Branches are incredibly useful. However, they do require a shift in your thinking. To use the analogy from the previous post, it takes time to understand that you can create alternate universes on your computer where you can work on your files, yet not change the version of your files in the real universe. If all this alternate universe talk is a little confusing, don’t worry. Things should make much more sense by the end of this post!
Assumption. You have completed all previous lessons and have a folder (repository) called
project_repothat contains three files:
Making your first branch
I have to make a confession, you already created your first branch. It was created when you initiated your repository back in lesson 1. Git creates a primary branch when you initialize a repository; by default it is called
master. Let’s see if I am telling the truth.
Make sure your current directory is
project_repo and then run the
git branch command. The output should look something like this:
20:24 ~/.../project_repo$ git branch * master
We see that you have one branch called
master in your repository. The
master indicates that
master is your current branch.
Let’s pretend you found an important bug in your program and you need to fix it. Because you don’t know how messy this bug fix will be, you decide to do your work on a new branch. Let’s use the
git branch <branch name> command to create a branch called
bug_fix_#001. Let’s also re-run
git branch to see if we successfully create our new branch.
20:27 ~/.../project_repo$ git branch bug_fix_#001 20:53 ~/.../project_repo$ git branch bug_fix_#001 * master
The output of
git branch shows that your repository now has two branches. The
* indicates that
master is still your current branch.
Before you learn how to access this new branch, have a quick look at the files in your repository:
20:53 ~/.../project_repo$ ls doc1_new.txt doc1.txt doc2.txt index.txt
Now inspect the content of our three tracked files:
21:12 ~/.../project_repo$ cat doc1_new.txt Line 1 of document 1. Line 2 of document 1. Line 3 of document 1. Line 4 of document 1. Line 5 of document 1. Line 6 of document 1.
21:12 ~/.../project_repo$ cat doc2.txt Line 1, doc 2. Branch master in project_repo. Line 2, doc 2. Branch master in project_repo.
21:12 ~/.../project_repo$ cat index.txt Start of the index file
Great! Now review the status of our repository before you move on:
21:23 ~/.../project_repo$ git status On branch master nothing to commit, working directory clean
Note that the output of
git status tells you that you are on the
Checkout your new branch
In Git, you make a branch your current branch by checking it out. If we go back to our alternate universe analogy, checking out a branch (i.e. having a look at what’s on it) is equivalent to being teleported to a new universe (or branch). It is important to remember that you can only be in one universe at a time, and this will be your current universe. Similarly, you can only be on one branch at a time, and this will be your current branch. Checkout your
bug_fix_#001 branch using the
git checkout <branch name> command:
21:25 ~/.../project_repo$ git checkout bug_fix_#001 Switched to branch 'bug_fix_#001'
You have now moved onto your new
bug_fix_#001 branch. This is obvious because the output shows that you switched branches. However, it is good practice to regularly verify what branch you are located on. Go ahead and use
git status and
git branch to confirm that you are on the
bug_fix_#001 branch. While you are at it, go ahead and verify what files are in this branch and what these files contain (you can do this by re-running the
cat doc2.txt and
cat index.txt commands you used above).
If everything went well, your
bug_fix_#001 branch should be exactly the same as your
Work on your bug fix
In this final part, to really see what branches are all about we need to go through the
work -> stage -> commit cycle on one branch and see what happened in the other branch. For now, let’s add a line of text to
doc1_new.txt, then stage and commit this change.
# Write new line of text doc1_new.txt echo 'Line 7, doc 1. Branch bug_fix_#001 project_repo.' >> doc1_new.txt git add doc1_new.txt git commit -m 'New line doc1_new.txt on branch bug_fix_#001'
Now that you have added a new line to
doc1_new.txt and have committed this change, have a look at your Git log.
As you might expect, the most recent commit is the one you just made. However, how has this affected your
master branch? Have a look:
git checkout <branch name>to change to your
cat doc1_new.txt(or open the file in a text editor) to confirm for yourself that the changes you made on the
bug_fix_#001branch are not present on your
git logto see that the
masterbranch is not aware of the commit you made on your
As a final verification, use
git checkout <branch name> again to change to your
bug_fix_#001 branch and confirm for yourself that the content of
doc1_new.txt now once again includes the change you previously made on your branch.
You have successfully created and used your first (non-
master) branch in Git using the
git branch and
git checkout commands. It will take a little time for you to get used to switching between branches, and understanding how branches relate to each other. However, once you understand how branches work, you will wonder how you ever managed without them!
In the next tutorial, you will learn to incorporate the changes you made in your
bug_fix_#001 branch into your