Learn Version Control with Git
A step-by-step course for the complete beginner
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.