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
- Do you seem to spend too much time getting code changes implemented and released?
- 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:
- What is the simplest, most effective development workflow available?
- How can I develop in the most efficient and error free manner?
- How can I roll out an error-free release without actually doing it?
- 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:
- git -distributed-even-if-your-workflow-isnt - By Scott Chacon of Github
- Introduction to Git with Scott Chacon of GitHub
- How GitHub Uses GitHub to Build GitHub by Zach Holman
- Linus Torvalds & git
- git-flow cheatsheet
- A successful Git branching model
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.
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...
- Fix a Commit History With Git Interactive Rebase
- 4 Git Command-Line Tips for Greater Productivity
- Easy Git Interaction with OhMyZsh and Git Extras
- How to Get GitHub-like Diff Support in Git on the Command-Line
- Use GitHub to Quickly Compare Two Branches and Create a PR of the Changes
comments powered by Disqus