When you’re new to the programming world, you may hear a word like branches and think of something like this:

Contextually, though, you know something is awry. Why would that have anything to do with your work?

Hint: It doesn’t.

Except for that whole “save the planet” thing.

…Seriously, though, we should take care of our environment. We live here after all.

Quick “How To” for branching with Git

As a new programmer, a lot of what I’ve done so far has been in my own GitHub repo with no one touching it but me. (Question: Who wants to touch the newbie’s code? Answer: No one. Duh.) As this is the case, it is really easy to get into the bad habit of pushing to the master branch. All the time. Well, most of the time. Perhaps a little unreliably, but that’s no big deal, right? I mean, you’ll just push it later. Maybe. When you remember and get around to it.

So yes. Really bad habits.

In an effort to break this habit, I decided to start making branches.

What is a branch?

If you want to read a bit about it and look at pretty diagrams, I recommend hopping over to git-scm’s “Git Branching – What a Branch Is” page. For now, I’ll just provide a TL;DR version:

  • By default in git you have a master branch, which is where you I have been pushing your my code this entire time.
  • When you create a branch, you can think of it as a copy of the code. Initially, both the master and newBranch are identical.
  • When you push edits to newBranch, master is unaffected.
  • When you want to include the newBranch edits in master, you merge the two branches.

Sounds like extra work…

…and it is, especially when your development team has only one member and that member is you, newbie :)

When used properly the main benefits, as I understand them, are:

  • Branches are only merged to master when their code is working. Therefore master is always working. Don’t we all wish that were a thing?
  • To get ready for the leap to a development team of 2+ developers, you’re going to want to branch so that your edits don’t mess up developer N’s edits (for N < numberOf(otherDevelopers)). (Likewise you don't want anyone else working on what you're trying to work on, right?)

So what do I do?

If you want to take this next step, then it's as easy as 1, 2, 3 (…4, 5, 6…):

  1. Create the new branch. If you're a GitHub user, you can do this in the web UI. Or you can do this in the command line with git checkout -b newBranch
  2. Edit some code.
  3. Push some code.
  4. Rinse, lather, repeat until the code is where you want it.
  5. Switch back to the master branch: git checkout master
  6. Optional (only as long as you're going solo): git pull origin master
  7. Merge the new branch into master locally: git merge newBranch
  8. Push the changes: git push origin master
  9. Delete the branch: git branch -d newBranch
  10. Push the changes (deleted branch) via git: git push origin --delete newBranch

That's it – you have now taken the next step into glory. Pretty awesome, right?

Yeah it is! I’m Super Programmer!

Easy, easy. Just be careful not to make it into the next episode of “Branching Gone Wrong”, ok? Remember:

  • Don’t have long running branches. From one of my mentors:

“The longer you have the branch – usually – the further it diverges from master. So, the greater chance of merge conflicts, and of other changes making their way to master that are incompatible with your long-running one, but that’s not noticed until The Great Merging, which by now is An Event because of the sheer amount of things that will change when it happens.”

  • Make sure to clean up after yourself and delete branches after they have been merged!

Reference: Git Branching Commands

  • git status : Outputs your current branch as well as if you have any uncommitted changes.
  • git checkout -b newBranch : Creates a new branch named newBranch and switches your current working branch to newBranch
  • git checkout branchName : Switches your current working branch to the branch named branchName
  • git branch : Lists all branches, current branch indicated with an *
    • git branch -v : Lists all branches with the last commit ID and message, current branch indicated with an * (-vv includes upstream branch)
    • git branch --merged : Lists all branches merged with your current branch, current branch indicated with an *
    • git branch --no-merged : Lists all branches not merged with your current branch, current branch indicated with an *
    • git branch -d branchName : Deletes the branch branchName locally if it has been successfully merged. If not, returns an error.
    • git branch -m currentName newName : Moves/Renames branch currentName to newName. If unspecified, currentName defaults to your current branch.
  • git push origin --delete branchName: Deletes branch branchName from GitHub (as opposed to git branch -d, which only deletes the branch locally).
    • git push origin :branchName : Same as above – the : prefix means “delete”. I personally don’t use this method because I don’t want to get myself in a situation where I have trained my fingers to quickly, accidentally, delete things I don’t actually intend to delete.

Update (1/8): Interactive site to learn Git Branching