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?
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:
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.
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:
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.
To quote this excellent post on Github Flow by Github’s Scott Chacon, here’s the core of the methodology:
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.
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.
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.
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.
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!
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.
Please consider buying me a coffee. It really helps me to keep producing new tutorials.
Join the discussion
comments powered by Disqus