GitFlow or GitHubFlow - Which is Right for You?

This week we look at two of the prevailing Git development workflows: GitFlow and GitHub Flow, weighing up the pros and cons of each.

Recently, I’ve been getting serious about Git, both learning it inside and out as well as the different development workflows which are commonly used with it. Why? Because I want to spend as little time as possible doing development.

This may sound rather strange when I’m a very active web application designer & developer having the good fortune of working with a healthy group of clients. But I’ve felt for too long that I spend too much time, as Michael Gerber would say, working in my freelance business, not on it.

Whether a freelancer yourself or not, perhaps you feel the same?

Ask Yourself These Two Questions

  1. Do you seem to spend too much time getting code changes implemented and released?
  2. Can you push a release simply by pushing to a remote repository?

I’ll be honest, my answers are, sadly, yes and no. Sad, but honest. But faced with this realisation, I decided to start at the beginning, with my development workflows. I asked myself a couple of questions:

  1. What is the simplest, most effective development workflow available?
  2. How can I develop in the most efficient and error free manner?
  3. How can I roll out an error-free release without actually doing it?
  4. What development workflow makes working with others a no-brainer?

So I’ve set about reviewing my entire development processes, seeking to implement an end-to-end workflow that meets these criteria. It was with that, that I turned to my use of Git, voraciously learning all I can in pursuit of the best answer to these questions.

A Bit of Background

For the last few years I’ve used it and called myself a git fan. But seriously, I’ve really barely used it more than the basics of clone, commit, diff, log & push. Despite tinkering with the more advanced features, such as interactive rebasing, I wasn’t even clear on the distinction between merging and rebasing, or pulling and fetching.

Like any intelligent person though, I turned to the source of all knowledge - Google. There I found a wealth of information of which the best, in my not so humble opinion is the following:

If you’re following Malt Blue on Twitter you’ll have seen these links, and more, racing by in the tweet stream. Of that information, two core development workflows appeared to dominate:

  • Git Flow
  • GitHub Flow

Whilst similar they’re sufficiently different enough workflows that I want to give you a 20,000 foot view of them; covering what they are and why they may be right for you. I’ll explain them in my own words, so if I paraphrase a bit, bear with me.

GitFlow Summary

Git Flow, the one that I currently use and am most familiar with, whilst not the simplest concept to initially take in, with free git extensions, is very simple to implement.

All development is based off of the develop branch and the live version is based off of master. When a new feature, change or update is to be added to the application, then a new &’_feature branch_’ is started off of develop, worked on and merged back with an annotated tag.

When a release is ready to roll out, a branch is made, again off of develop, final work and preparation are completed and the work merged back to master as well as develop. This way, all of the final work is ready to be deployed to your servers and is also available for continuing work, basing the next version on etc.

If, after the next release is rolled out a bug is found, a &‘hotfix’ branch is created off of master. This allows for minor changes and updates to the existing release, without disrupting ongoing development of future releases.

Github Flow Summary

To quote this excellent post on Github Flow by Github’s Scott Chacon, here’s the core of the methodology:

  • Anything in the master branch is deployable
  • To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
  • Commit to that branch locally and regularly push your work to the same named branch on the server
  • When you need feedback or help, or you think the branch is ready for merging, open a pull request
  • After someone else has reviewed and signed off on the feature, you can merge it into master
  • Once it is merged and pushed to ‘master’, you can and should deploy immediately

What’s the Difference

In essence, as I see it, GitFlow is better if you have longer development cycles and a more structured development process or organisational structure.

Github Flow on the other hand is much more lightweight and very effective if you do a number of smaller updates or turnaround features on a much shorter timescale such as daily or hourly.

It lends itself very well to a nimble developmental style, whereas Gitflow is a much more, for want of a better descriptor, methodical process. It’s a bit more heavyweight shall we say.

I’ve been using Gitflow for the last 2 - 3 months and have no issue with it. As I’ve been tweeting about lately, I’m very enchanted with it and have found it improving the quality of my work with no end in sight.

But after beginning to investigate Github Flow recently, it may be a better approach to take for me as a freelance PHP developer. I have the choice to work either stand-alone or with a series of sub-contractors in a loose-fitting arrangement. So a wide range of work can all happen remotely, collaboratively, with no large organisational hierarchy or checklists to satisfy.

Which is Right for You?

Honestly, I can’t answer that for you. I can however show you and talk about both. But ultimately, it’s up to you to decide, based on your organisation, needs, developer skill levels and any other relevant factor.

I encourage you to use the links available in this post, read up on both and try out each - then decide for yourself. Whether you go for one or the other, you will improve.


So that’s a brief, 20,000 foot overview of two of the predominant git-based workflows in use today. I’ve kept the description of both intentionally brief, focusing more on why you might go with one or the other.

So now it’s your turn. Do you already use one? Why? Does the other hold enough to get you to experiment with it? Share your experiences in the comments.

You might also be interested in these tutorials too...

Fix a Commit History With Git Interactive Rebase
Thu, Nov 28, 2019

Fix a Commit History With Git Interactive Rebase

Git interactive rebase is a powerful tool that can help you fix up your commit history to make it more meaningful, professional, and maintainable. In this post, I step through what it is, how it works, and when you should — and shouldn’t — use it.

4 Git Command-Line Tips for Greater Productivity
Thu, May 23, 2019

4 Git Command-Line Tips for Greater Productivity

Git, despite still being a bit terse, is extremely powerful version control software. However, because it’s so powerful, it takes time to learn. In this post, I’m going to show you four small techniques to help you use it more effectively.

Mon, Oct 16, 2017

Easy Git Interaction with OhMyZsh and Git Extras

Git is known to be incredibly terse, though it has improved in recent years. What’s more, there’s a plethora of commands that you need to remember. So, why not learn about OhMyZsh and Git Extras and make your life with Git easier!

How to Get GitHub-like Diff Support in Git on the Command-Line
Thu, Aug 24, 2017

How to Get GitHub-like Diff Support in Git on the Command-Line

If you use Git as your VCS (version control system), you’ll know that it has excellent diff support on the command line. However, even as good as it is, it still leaves a bit to be desired — at least when compared with tools such as GitHub.

Want more tutorials like this?

If so, enter your email address in the field below and click subscribe.

You can unsubscribe at any time by clicking the link in the footer of the emails you'll receive. Here's my privacy policy, if you'd like to know more. I use Mailchimp to send emails. You can learn more about their privacy practices here.

Join the discussion

comments powered by Disqus