I’ve been doing this particular git thing for a while now and thought I’d write it up in case it helps any other intermediate-gitters out there.

So. Branches. Branches are great right? If you answered that question with any reservations, then this post is for you. A year ago, I knew the benefit of branching in Git, but it always seemed to come with some level of agony. It was essential, but not pain free. Now, a year later, it’s almost 100% painless. Let’s walk through a real quick workflow example.

So, you’re working on some fairly significant frontend changes. Let’s say you’re re-responsive-izing an entire site. You’ve branched off master to your own feature/new-responsive-site. You’re making changes to lot’s of php and sass files, and you’re compiling new versions of min’d files with grunt. IE: you’ve got a lot of changes brewing. What’s going to happen when you’re “done” and you try and merge back into master? If the rest of the team has been working on those same files, you know exactly what’s going to happen:   you’re going to spend Friday night crying and resolving approximately 75 massive conflicts. But mostly you’ll be crying.

If you’re still at the place where you’re crying and resolving conflicts all the time, you’ve missed a huge PRO TIP that took me ages to catch on to.

Let’s say the responsive work takes you 4 days. So you’ve not merged into master in 4 days — and a lot has happened since then. If you go to merge into master at this stage, it’s going to be an absolute nightmare. But what if you merge master into feature/new-responsive-site before you merge your branch into master? Here’s an even better question:  what if you merge master into feature/new-responsive-site every day? What about two or three times a day?

What happens is: you stop crying, and stop fixing (most of the) conflicts.

If you regularly (at least daily) merge master into your feature branch you’ll be resolving waaay less conflicts, and you’ll be able to react to the new code that’s getting pushed to master. It puts you back in control with your feature instead of having to react to a whole bunch of stuff that’s happened in the last 4 days. You’ll still have conflicts for sure, but you’ll have way less of them, and you’ll be able to ping the other developer who just wrote the thing that conflicts with what you’ve written. So resolving these conflicts should take you far less time.

On some recent projects, I’ve been merging master into my feature branch all.the.time. Sometimes I’ll watch for another team member’s commit and pull that in right away if I know it’s coming in contact with my code.

So that’s it. Not a huge-huge thing, but definitely a lightbulb moment that I had this year, and that I definitely didn’t see out there when I was just learning Git. Start using it, it’ll definitely save you a bunch of tears and time.

ps: To pre-empt the:  “Are you sure this is a good idea?”.   Yep it’s a good idea. If you’ve branched off master, there’s nothing in your feature branch that shouldn’t be there, so you’re gold to start with. If you merge master back into your feature you’re getting all that sweet-sweet code that your team members have been working on. Here’s the trick: there’s no risk there because that code that your team members have added to master is ready for production, so it will definitely be merged with your code eventually anyway. Why not just go ahead and do it now?

I’ve known for a while that you shouldn’t commit to your master branch in Git. I’ve seen random tweets about it, read a blog post or two when someone talked through their workflow, but it never really clicked why you wouldn’t want to commit to master all the time. Until yesterday.

The scenario: So, I was working on a website that has been live for a few months now. I’ve been regularly pushing fixes and new features by just committing to the master branch and pushing that: Add some new footer info, change a few css styles, add a few lines of jQuery, etc. No sweat.  I’d just make the changes, commit and push them, and then they were live. The trouble reared its head yesterday as I was working on a fairly large new feature. The changes spanned about 5 different files, and nothing was ready to go live yet. My coworker messaged me saying—”I just added a table to a page, but it’s completely unstyled. Do you need to add some css?”

Here I was, with a ton of changes made to a pile of different files, my local master is about 10 commits ahead of my live master, and I need to push about 5 lines of css.

What did I do? In the end, I was able to use Github’s app to select and commit only the lines I needed in my css file, and run git push origin XXXXXXXXXX:master with the latest commit id. The problem was that I ended up doing that all day. Pushing individual commits to the live server all day is really, really stupid.

What I should have done: A month ago, when I started working on that new big feature, I should have created a new branch for it. If I’d done this, pushing those table styles yesterday would have been really painless. Basically, I would have had three branches yesterday:

1. master
2. new_feature
3. table_styles

I would have worked in the table_styles branch, writing all my css there, and then merged the changes into master before pushing it live. When I was done merging, all I needed to do was delete the table_styles branch, and I’m all set to continue working in new_feature.

The takeaway advice: (Clearly) I’m no Git expert, but next time you commit to master, ask yourself if what you’re working on shouldn’t be happening in a new branch, and get merged into master when you’re done. My new practice is creating a new branch for every new thing I work on. This way, master will always be ready for quick hotfixes and minor changes.

I’m a complete noob, I know! Maybe I didn’t know before, or maybe it was just laziness, but yesterday was literally my first a-ha moment with this. If you’re just starting with Git, you should really get into the habit of using branches. The official guide will do a great job of showing you how to use branches, and I hope I’ve just done an ok job at showing you why you should.