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? The "git status" command tells us in its first line of output: "On branch master".
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. Based on the project's current state, we create a new branch and name it "contact-form":
$ git branch contact-form
Using the "git branch" command lists all of our branches (and the "-v" flag provides us with a little more data than usual):
$ git branch -v
contact-form 3de33cc Implement the new login box
* master 3de33cc [ahead 1] Implement the new login box
You can see that our new branch "contact-form" was created and is based on the same version as "master". Additionally, the little asterisk character (*) next to "master" indicates that this is our current HEAD branch. To emphasize this: the "git branch" command only created that new branch - but it didn't make it active. Before checking out that new branch, it's a good idea to have another look at "git status" to see where we currently are:
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
# modified: imprint.html
no changes added to commit (use "git add" and/or "git commit -a")
Oh, right: we still have some changes in "imprint.html" 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.
Get our popular Git Cheat Sheet for free!
You'll find the most important commands on the front and helpful best practice tips on the back. Over 100,000 developers have downloaded it to make Git a little bit easier.
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.