by 
On the eighth day of Christmas, my true love gave to me… eight different branches.
In the previous lesson, we learned about keeping your Git repository up-to-date with others’ changes by configuring an upstream remote and pulling new changesets from that remote. Today, we’re going to return to our example Santa Tracker repo, and learn about using Git to experiment safely.
If you are following our song, “The Twelve Days of Git,” here are the verses so far:
- The 12 Days of Git: Learn Git over the Holidays
- The 12 Days of Git, Day 2: Tracking Files with Git
- The 12 Days of Git, Day 3: Viewing Git History
- The 12 Days of Git, Day 4: Double-checking Changes with Git
- The 12 Days of Git, Day 5: Sharing Changes Remotely with Git
- The 12 Days of Git, Day 6: Making a Copy of a Git Repository
- The 12 Days of Git, Day 7: Keeping Your Git Repository Up-To-Date with Others’ Changes
Today, we will learn about a powerful Git feature called branching, which allows you to split off from the main line of your work and experiment, without affecting the main line until you are satisfied with your experimental work.
In this lesson, we will create a new branch in our repo. We can commit changes to just that one branch, and move between different branches (versions) of our repo.
Go to your santa-tracker folder and enter the following command to see what branches are already in your repo.
git branch
You should only see this output, which lists the default branch—master—that is created whenever you do a git init or git clone.
* master
The asterisk (*) indicates the branch that you are currently working on.
Whenever you link a repo to a remote copy, like one on GitHub, the linking process also creates branches which track the branches on that remote. You don’t normally see these branch in the output of the branch command, unless you specify all branches with the -a option, like this.
git branch -a
You should now see this output, which lists both the master branch and a branch which tracks the master branch on the origin remote.
* master remotes/origin/master
Creating a Branch
So far, so good. Now, let’s create an experiment. Enter the following command to create a branch called father-christmas.
git branch father-christmas
Now, when you run the plain git branch, you will see the new branch you just created.
father-christmas * master
You may be wondering what you actually created when you created the father-christmas branch, and how it is different from the master branch. Well, at this point it’s NOT different at all. Branches in Git are just names that point to a particular changeset. When you created a branch while on the master branch, you merely created a new name pointing at the same changeset that master was already pointing to. You can see this visually by running the comprehensive version of the git log command that we learned on the third day of Git.
git log --graph --decorate --pretty=oneline --abbrev-commit --all
This will give you the following output, which lists all your branches as pointing to the most recent changeset’s commit hash. (Your commit hashes will probably be different.)
* 384888c (HEAD, origin/master, master, father-christmas) Change branding style of the website * 8bfbaa2 Add first files to the repository
Using a Branch
Now that we have this new branch, let’s use it. Git refers to using a branch as “checking out a branch”, and the command to do that is git checkout. Type that command with the name of the branch you want to use.
git checkout father-christmas
The output will be,
Switched to branch 'father-christmas'
and now a git branch command will show an asterisk (*) beside father-christmas.
Let’s change a file. Open the index.html file and change each instance of Santa to Father Christmas.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Father Christmas Tracker: Bringing the North Pole to You</title>
<link rel="stylesheet" type="text/css" href="main.css">
</head>
<body>
<h1>Father Christmas Tracker</h1>
<p>Bringing the North Pole to you since 2015</p>
</body>
</html>After you save your changes, a git status will show those changed lines.
You could use git add to stage those changes, and then git commit to save those staged files as a changeset. However, if you include the -a option with git commit, that command will add any changed files and commit them at the same time. Let’s try that.
git commit -am'Change Santa to Father Christmas'
The only caveat to using this shortcut is that git commit -a will only add changes to files already tracked in the repo. If you create a completely new file, you need to start tracking it with git add and then commit it.
Now run the comprehensive log command again.
git log --graph --decorate --pretty=oneline --abbrev-commit --all
Notice in the output that the branch named father-christmas is beside the third, most recent commit hash, but the master still points to the second commit hash. Also notice that a label we have ignored up until now, HEAD, has moved along with father-christmas to point to the latest commit.
* 7f67565 (HEAD, father-christmas) Change Santa to Father Christmas * 384888c (origin/master, master) Change branding style of the website * 8bfbaa2 Add first files to the repository
The HEAD label shows what version of a repo you currently have checked out. To see this in action, check out the master branch again.
git checkout master
Now run the comprehensive log command above a third time. You will see that HEAD has moved back to point to the second commit. If you look at the index.html file, you will see that it is the Santa-version.
* 7f67565 (father-christmas) Change Santa to Father Christmas * 384888c (HEAD, origin/master, master) Change branding style of the website * 8bfbaa2 Add first files to the repository
You can checkout the father-christmas branch again, and continuing working from there, or you could stay on master and base your work off it instead. You could just save the father-christmas branch for later, in case you ever move to the British Commonwealth.
Today, we’ve seen how branching can be a very powerful tool for experimenting safely while using Git. Be sure to come back for tomorrow’s verse, when we’ll learn about The 12 Days of Git, Day 9: Using Remote Branches with Git.
To see all the options available for the commands we’ve discussed today, check them out in the online Git reference: