12 Days of Gitmas: Git Branches

On the ninth day of Gitmas, my mentee asked of me… what a branching strategy?
what’s this gitignore thing,
push-ing, pull-ing, diff-ing,
what is SSH-ing,
how do I connect these,
what’s this “GitHub” of which I’ve heard,
Git’s ready – what then,
how do I get Git set up,
and could you explain Git, pretty please?

We’ve reached Day 9 of the 12 Days of Gitmas, and today we’re going out on a limb… and talking branches!

If you’re working on a very small project by yourself, you may not need branches. But for the majority of projects – if you’re working on a team, or if you want to work on features that won’t go to production yet – branches will be an important part of your Git experience!

When we introduced how to check in your changes, I mentioned that you should do git push origin master, and that I’d explain what that meant more in the future. Well, the future is now!

git push you already know – git is to signify that the command should use Git, and push means you’re pushing your changes to the remote repository.

origin is a shorthand that refers to the remote repository that the project was originally cloned from.

master is the branch you’re on. By default, when you initialize a Git repository, it will have a single branch – the master branch.

When you run git init, you start on the master branch.

What is a branch
When you’re working on a project, you want to be able to check in your changes and “save your work” on a regular basis. But what if you’re not ready for your changes to be in production? What if you’re working with other people, and need approval before your changes get into the main codebase? What if your team wants to have one version of the codebase on production, and develop and QA the next version before it goes to production?

This is where branches come in.

Think of your repository like a river. Every repository starts with a single branch, called master.

The river can branch off into smaller streams, which could, at some future point, merge back into the main river. This is essentially how branches work in Git.

You can create a branch off of master, at which point the code in the master branch and your new branch will be exactly the same. But from there, the original branch will carry on as it is, but any new changes you make in the new branch will live independently from master. At a future point, you can merge your new branch back into master, which will bring your new code into master, but up until then, the master branch won’t know anything about the new changes you’ve made on a different branch. (We’ll talk about merging and PRs in the next post!)

Many projects will have a master branch for what goes to production, and then a develop branch (or something similarly named) that all the developers will work off of. In this case, the developers will branch off of develop, since that is the branch with the most up-to-date code. Once the codebase on develop is deemed ready for production, then they’ll merge develop back into master in the process of pushing the new changes to production.

Okay – so we’ve got the theory, now how do we make this all work in practice?

Creating your own branch
To create a new branch, run:
git checkout -b [branch name]
Make sure the branch name is a string with no spaces: new-branch, rather than new branch (This should be the case for all naming in Git – branches, repositories, file names, etc.)

Pulling down new branches
Sometimes, you’ll want to work on a branch that somebody else created, or run the code on their branch while code reviewing a PR. In order to do that, you’ll first have to make sure their branch exists on your local machine. To pull down all the new branches that exist remotely, run:
git fetch origin

Checking out someone else’s branch
Once you’ve fetched all the remote branches, you can checkout the branch you want. This command is similar to the one you ran to create your own branch, but note that this time, you won’t have the -b in the command:
git checkout [branch name]

From there, you can git pull to pull down their latest changes, or git commit and git push to add your own changes to their branch. Always make sure you have permission to be working on someone else’s branch!

Now you know all about Git branches and how to use them. In the next post, we’ll be talking about merging branches and PRs!

If you have any other questions about Git or requests for other topics you’d like to see me blog about, please leave a comment! And if you’re enjoying this series, consider supporting me on Patreon, following me on Twitter or checking out my coding or cooking Twitch streams!