Simplifying branching and deployment with GitHub Flow
First posted 14th December 2019 in Development and Git; updated 27th December 2019
I’ve been using GitFlow for a long time. It’s a solid system for developing collaboratively and ensuring changes are made in a controlled, granular fashion. But it’s not unusual that I sit on a release for over a week; all the while building little features and fixing the odd cheeky bug, but holding onto it all until it feels ready to be called ‘release’.
This is fine on larger projects, but for my own website and one or two other projects I work on it’s too heavy. Ideally I’d want the bug fixes and features to be released the moment they are ready.
GitHub Flow is the answer for those projects where I want to stay light-weight and ship as regularly as possible.
No more release branches
With GitHub Flow, a release should be made every time a feature or fix is made, instead of raising pull requests (PRs) for features and fixes and a separate PR when a release feels appropriate.
This means that updates happen the moment they’re ready, rather than waiting to be bundled in a release.
Rather than maintaining both a
develop branch, GitHub Flow only needs
master. Features, not just hotfixes, are branched from
master and merged back into
master via their PR.
With my website’s setup, when the work is merged into
master on the remote, a deployment is triggered and the work goes live. I’ll then pull
master back down and continue work.
I’ll probably still prefix my branch names with
post/, etc. so that it’s easier to identify what type of work was involved at a glance.
My only concern is versioning. With GitFlow, I use the release branches to:
- update the changelog
- bump the version number
- tag the commit
I’ve been doing 1. manually, and 2. and 3. using the version-bump-prompt npm package. I’ll carry on doing this at the end of every piece of work, but for collaborative projects that’s going to cause both merge conflicts and versioning issues.
And if a PR needs work after the branch has been tagged, the tag will have to be deleted and re-added to the final commit. Update: I’ve sorted the tagging part of my process by adding the tag after the PR has been merged.
I’m going to have to work out how to automate this as part of the PR/merge process. I’ve got a feeling that running some scripts via GitHub Actions will be the answer, but that’s another story for another blog post!
In the meantime, I’ll be shipping each thing I build the moment it’s ready.