Git to it

Workflows are like assholes; everyone has one. And, while there’s not necessarily any right or wrong way to approach version control, I’d like to share the way that I approach it in my own words.

When you have several developers working on the same repo it becomes increasingly important to utilize branches. This goes for bugs, features, hotfixes, and releases. The method I use isn’t new at all, it’s referred to as GitFlow workflow, and Tower 2 even has this built right in (it takes care of creating the branches and streamlining the actual process of creating and merging branches).

So, let’s start with two branches; master and dev. Master branch is the branch that is currently live to the world. You never work directly in Master. Dev branch is like a hooker; always dirty. Like master, you also neverwork directly in dev (unless you’re rolling solo with no collaborators). Two branches, and let’s assume right now that they’re both identical.

Fixing Bugs

Time to fix a bug. You branch from Master, and call it bug/nameofbug. The reason for the slash is that Github and git clients will organize those into folders. You work on your bug, directly in your bug branch, and when fixed, you merge your bug branch into dev branch.

At this point the dev branch is then automatically deployed to a staging environment. Once it passes all tests, you create a second branch from master called release/dateofrelease. Your release branch now contains the fixes that are to be deployed next. If you have more bugs, create more branches, and merge those branches into the release branch. You can also work directly into the release branch if the bugs are minor. The key to everything here is that bug fixes remain encapsulated wihtin their respective branches the entire time.

So we’ve got our release/releasedate branch and we’re ready to deploy some code. Merge release into master branch. Then merge master branch back into dev branch. This ensures that master and dev are now back in sync.


Hotfixes work in a similar manner, but here we skip the release branch. So branch from master and call it hotfix/name. Once you fix it, you merge this directly back into master and deploy it to live. Then, merge that hotfix branch back into dev branch.

Make sense? It may seem daunting at first, and I admit it took me quite some time to get the hang of things. But I assure you it’s worth it and the workflow is proven.

More Infoz

If you’re working with Grunt and have your SCSS or LESS files automatically compiled, you may run into an issue where you constantly have to recompile. What happens is, when you merge your code into another branch, those files haven’t had a chance to compile into the new css file yet, so the css file that is there will technically be old. I recommend either not compiling until after you merge, or simply recompile after merge. I will mostly stick to the first method because it just seems easier.