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?