Using Git Branches

Read time: 25 minutes (6479 words)

Suppose you are working on a project, and you have a great idea about something you think might just work, and help the project get to its delivery point quicker. You are in the middle of working on something else, but you want to try this idea out.

Doing so, especially if this idea fails to work, risks messing up the project. It would be better to work off to the side of this project and try your idea out there.

In the old days, you might make a copy of the entire project and move to that copy and experiment. After the smoke clears, you will struggle with your new code, trying to patch the work back into the “real project”, your original working directory.

That was the old way. The new way is better!

Isolating Development with Git

What you really want to do is isolate the changes you are about to make to your project at this point in time. You do not want to risk messing up the current project code, but you need to be able to change things. You will try out your new idea, and potentially throw the whole thing away if it does not work out. If it does work out, somehow you will need to mash the two versions of the project back together! Phew!

Git_ knows exactly how to manage this! All you need to do is create a branch off of your current development timeline, and work on that branch to try out your idea!


Git Timelines

When you use Git_, you work over a period of time, then reach a point where you want to save the current state of your work. Many developers absolutely will not walk away from their stations without doing a commit. That protects the code by making a hidden backup copy. Even better, they push that backup copy to a remote server like GitHub_. Now they are really safe from harm.

Draw a line representing your work over a period of time, and draw bubbles at various points along the line. Each bubble represents a commit, and it has a name that is practically useless to humans. Git_ creates a 20 character “hash code” that will be unique for that particular commit, and slaps that name on the commit.


It is possible to create something called a tag with a human friendly name, and attach that to a commit, we will explore that later.

You may already have seen references to the master branch when you create a new commit. Git_ calls this timeline of development a branch, and by default, names the first branch you work on “master”.

So far, that is the only branch we have been working on!

Back to our development work.

Make Master Special

What we are going to do is stop using the master branch for normal development. Instead, we will only create commits on that master branch to mark a point when the project is ready to be released, (graded in academia). Any commits on the master branch will be treated specially. They may be headed to our users, so they better work well!

So, Where Do We Work?

All real development work will happen on a branch. Graphically, branches look like this:


We will run a special Git_ command to create the branch, and we will then “switch” to that new branch. Git will track our progress, and new commits will be recorded on the new timeline.

Switching Branches

Once we have more than one branch, we can hop back and forth between them. This is pretty cool. If you think about it, each branch has potentially very different versions of the project. Git_ will make your single working directory look right for what ever branch you want to work on. How it does this magic is explained in the ProGit_ book I referenced when we began using Git_

If you have several ideas, create several branches one for each idea, and work away!

Merging Branches

The scary point in time comes when you decide this idea needs to be integrated with the “safe” version of the project, to create a new “safe” version. This is called merging, an it has its potential risks.


If you are developing alone, nothing really happened back on that master branch while you worked on your idea! Your new version is just fine, and all you really need to do is get this version back on the master branch. In fact, at this point, there is no real reason to keep that branch around, we could move all of that work back onto the master branch line (too maintain a record of the development), or we could toss the history of those old commits and just retain this new version.


I like keep all of the history, so I do not let Git_ do anything to my idea branch, I just merge the final results back to the master branch.

Team Development

If you are part of the team, changes in the project code may well have happened while you were off working on your idea. Now when you try to merge your changes, the version of some file you used to create your new code may not match the version there now!



This situation is called a conflict. Git will try to merge all of the changes, but ultimately, the humans who created this situation may need to resolve the conflict by editing the offending file (or files). When everything again looks smooth, that new version is committed, and the project is again in a stable state. Work on the branch could stop, and a new branch could be created to begin work on a new idea.


If your idea does not seem to be going anywhere, you do not need to toss the work you did. Git_ will happily keep that development timeline in place. You will just never merge it back in. You could return to the idea later, and pick up where you left off. It is even possible to create branches off of other branches! Yikes!

Testing The Project

How do you really know that your project is stable when those commits happen. You can ask that question at any point in time, even while working on your idea.

The answer is simple,! You test your code!


Well, for some developers, you compile it, run it with a few sample cases, and walk away happy.

Not good!

You should not be happy with that simple “test”!

Testing like that really does not do what testing needs to do. It does not give you confidence that your project is ready for those very unusual users out there. Those users will never do what you expect, they will do the unexpected, and you will watch your (untested) code explode!

(Ask me how I learned this!)

The golden rule of testing is this:

If you have not tested it, it does not work!

Prove me wrong. By the way, that rule applies to every line of code in your project!

We will introduce a simple testing scheme you can use for C++ development. It is simple, and using Git_ and GitHub_, augmented with support from TravisCI_ I think you will find this new development scheme really cool!

Once I started working this way, I never looked back! And that started over two decades ago, before Git_ even hit the planet!