Working with Branches
Branches aren't optional; you're always working on a specific branch. Here's how to determine which branch is currently active and how to create new ones.
Working with Branches featured image

Working with Branches

Until now, we haven't taken much notice of branches in our example project. However, without knowing, we were already working on a branch! This is because branches aren't optional in Git: you are always working on a certain branch - the currently active, or "checked out", or "HEAD" branch.

So, which branch is HEAD at the moment?

Tower tells you both in the sidebar (appending "HEAD" to the current branch) and in the Working Copy view, on the top.

The "master" branch was created by Git automatically for us when we started the project. Although you could rename or delete it, you'll have a hard time finding a project without it because most people just keep it. But please keep in mind that "master" is by no means a special or magical branch. It's like any other branch!

Now, let's start working on a new feature - the "contact-form" feature.

Creating a New Branch

We'll create a new branch, based off of the "master" branch. To do that, drag "master" and drop it on the BRANCHES section header in the sidebar.

We'll create a new branch, based off of the "master" branch. To do that, right-click "master" in the sidebar and choose "Create New Branch from master".

In the dialog that follows, we'll enter "contact-form" as the new branch's name and confirm with the "Create Branch" button.


The sidebar now shows that a new "contact-form" item was created. Note, however, that we only created that new branch - we didn't make it active. Before checking out that new branch, it's a good idea to have another look at our current Working Copy status:

Oh, right: we still have some changes in "icon.png" in our working copy! Actually, we just wanted to start working on our new "contact-form" branch; but these changes don't belong to this feature. So what do we do with them? One way to get this work-in-progress out of the way would be to simply commit it. But committing half-done work is a bad habit.

The Golden Rules of Version Control

No. 4: Never Commit Half-Done Work

You should only commit code when it’s completed. This doesn’t mean you have to complete a whole, large feature before committing. Quite the contrary: split the feature’s implementation into logical chunks and remember to commit early and often. But don’t commit just to get half-done work out of your way when you need a "clean working copy". For these cases, consider using Git’s “Stash” feature instead.

About Us

As the makers of Tower, the best Git client for Mac and Windows, we help over 100,000 users in companies like Apple, Google, Amazon, Twitter, and Ebay get the most out of Git.

Just like with Tower, our mission with this platform is to help people become better professionals.

That's why we provide our guides, videos, and cheat sheets (about version control with Git and lots of other topics) for free.