Learn Version Control with Git
A step-by-step course for the complete beginner
Checking Out a Local Branch
Now that we have a clean working copy, the first thing we have to do is switch to (or "check out") our newly created branch. The easiest way to do this in Tower is to simply double-click the branch in the sidebar.
Checkout, HEAD, and Your Working Copy
A branch automatically points to the latest commit in that context. And since a commit references a certain version of your project, Git always knows exactly which files belong to that branch.
At each point in time, only one branch can be HEAD / checked out / active. The files in your working copy are those that are associated with this exact branch. All other branches (and their associated files) are safely stored in Git's database.
To make another branch (say, "contact-form") active, the "checkout" command is used. This does two things for you:
- (a) It makes "contact-form" the current HEAD branch.
- (b) It replaces the files in your working directory to match exactly the revision that "contact-form" is at.
Since we're now on branch "contact-form", from now on all of our changes and commits will only impact this very context - until we switch it again by using the "checkout" command to make a different branch active.
Let's prove this by creating a new file called "contact.html" and committing it:
Looking at the commit history, you'll see that your new commit was properly saved. No big surprises, so far. But now let's switch back to "master" and have a look at this branch's history once more:
You'll find that the "Add new contact form page" commit isn't there - because we made it in the context of our HEAD branch, which was the "contact-form" branch, not the "master" branch! This is exactly what we wanted: our changes are kept in their own context, separated from other contexts.