Version tagging with Releases in GitHub Flow

Posted in Development and Git

In order to keep things as simple as possible and release work as soon as it’s done, I’ve started using GitHub Flow instead of GitFlow for work on my personal website. The flow itself is much simpler but one of the hurdles I encountered was tagging.

Why tag?

If it presents a problem, couldn’t tagging just be dropped from the process? This is always a good way to approach a problem – maybe I was over-engineering things before!

Tagging definitely could be removed, but I think tags serve a useful purpose: they provide nice way to see a snapshot of a codebase at a particular point in time with something like:

git checkout -b branch-name v5.6.1

This creates a new branch at a particular tag (just change v5.6.1 to whatever your tag name is), so you can have a poke around and even make changes if you like. When you’re done, just get rid of the branch with:

git branch -d branch-name

(Use a capital -D to force the delete if you’ve committed changes.)

I use Netlify, so I could just use Deploy Previews to check out what my website looked like at a particular release, but I’d have to dig through the .changelog file to get the date, then find it in the Deploys list. Deploy Previews don’t allow you to play around with the code itself, either – just the generated website. But my real issue with this is that it’s proprietary and separate from the codebase – if Netlify ever falls out of favour I’d lose those snapshots. With tags, they’re always going to be there.

How to tag with GitFlow

With GitFlow, tagging is done as part of a release, which is a branch and a pull/merge request (PR) of its own. Anyone reviewing the PR would be very unlikely to raise an objection that required a code change and a new commit, so the tag was always going to be on the final commit of the PR. In exceptional circumstances, the tag would have to be deleted and re-added to a more recent commit. A bit of a fiddle, but a rarity so not a big deal.

If the tagging is happening with every PR, as it is with GitHub Flow, the likelihood of having to remove and re-add a tag is much higher. Any changes required as a result of some feedback on a PR would mean tags would have to be removed from the previous ‘final’ commit and re-added to the new final commit. It’s not the faff itself, it’s that that makes it not the right way to do it.

How to tag with GitHub Flow

The solution with GitHub Flow is to move the tagging step of the process from the PR to after the PR has been successfully merged back into master, adding the tag to the merge commit on the master branch. No more deleting and re-adding the tag to a later commit in the PR.

GitHub Releases

GitHub’s Releases are a really powerful way to tag (GitLab also has this feature). A Release creates a tag, so instead of tagging locally, it’s all done on GitHub.

This is a good idea because:

  • I often forget to run git push --tags, and wonder why my tags aren’t appearing on the remote repo – not a huge problem when I’m working on my own, but with a team it’s not something I want to forget
  • You can view the Releases in a handy timeline in the Releases section of your repo, alongside Commits, Branches and Contributors
  • You can do more than just tag in a Release – you can give your release a title, message (including images!), and add other files (like a database)
  • Each Release gets its own URL that you can tweet, send to your boss, etc.

Almost there

Fixing tagging doesn’t solve all my challenges with switching to GitHub Flow for certain projects. I’ll still have issues with: conflicts in the .changelog file when multiple people are working on the same codebase. Again, I’ve got a feeling that this can be solved with GitHub Actions to build the changelog automatically.

I’ll also see if I can use Actions to automate each Release, but for now I’ll be doing it manually.

Get them delivered!

If you enjoyed this and want all the latest articles delivered to your inbox every month, pop your email in the form below.

I don’t collect any data on when, where or if people open the emails I send them. Your email will only be used to send you newsletters and will never be passed on. You can unsubscribe at any time.

More posts

Here are a couple more posts for you to enjoy. If that's not enough, have a look at the full list.

  1. An introduction to HTML attributes

    An HTML attribute lives on the opening tag of an element and gives that element powers it might not otherwise have had.

  2. A handy Git shortcut to fetch and prune

    I’m still writing my Git commands long-hand. Turns out a fetch and prune can be more concise than I’ve previously suggested, all without aliases.