12 Days of Gitmas: Git Branches
Tags: beginners, git, github, tutorial
Published: 2020-01-24 21:24:51

*On the ninth day of Gitmas, my mentee asked of me...
__what a branching strategy?__
[what's this gitignore thing](https://dev.to/sushicodes/12-days-of-gitmas-gitignore-2ll0),
[push-ing, pull-ing, diff-ing](https://dev.to/sushicodes/12-days-of-gitmas-committing-your-changes-in-git-53nk),
[what is SSH-ing](https://dev.to/sushicodes/12-days-of-gitmas-ssh-vs-https-19bp),
[how do I connect these](https://dev.to/sushicodes/12-days-of-gitmas-connecting-your-local-repository-to-github-1d9h),
[what's this "GitHub" of which I've heard](https://dev.to/sushicodes/12-days-of-gitmas-what-is-github-11po),
[Git's ready - what then](https://dev.to/sushicodes/12-days-of-gitmas-your-first-git-project-g3m),
[how do I get Git set up](https://dev.to/sushicodes/12-days-of-gitmas-setting-up-git-39i8),
[and could you explain Git, pretty please?](https://dev.to/sushicodes/12-days-of-Gitmas-intro-to-Git-4l26)*

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](https://dev.to/sushicodes/12-days-of-gitmas-committing-your-changes-in-git-53nk), 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](https://dev.to/sushicodes/12-days-of-gitmas-committing-your-changes-in-git-53nk) - `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.

![screenshot of git init showing master branch](https://live.staticflickr.com/65535/49223160578_190b1ce094_o.png "when you git init, you start with the master branch")
<figcaption>When you run <code>git init</code>, you start on the <code>master</code> branch.</figcaption>

**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.

![gif of a river splitting into smaller streams and merging back together again](https://media.giphy.com/media/XAe9aDBIv3arS/giphy.gif)

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](https://www.patreon.com/sushiday), following me on [Twitter](https://twitter.com/sushiday) or checking out my [coding](https://www.twitch.tv/sushicodes) or [cooking](https://www.twitch.tv/sushiday) Twitch streams!