Version Releases and Git Tags for Beginners

Version Releases and Git Tags for Beginners

How to release an actual version of your web app on Github


3 min read

I didn't know this was a thing.

Well, I take that back. I knew about versioning and releases, i.e., 1.0.2. But until I tried to slap a version on my own web app on Github, I didn't realize there was a little bit of work necessary to set things up correctly.

Semantic Versioning, What?

Semantic Versioning is something you're probably already familiar with if you've done so much as download an update to one of your iPhone apps. See those three numbers in the picture below? The represent major, minor and patch releases of a piece of software.

Without getting into the weeds too much (you can read this if you want to go deep):

  1. the major number represents changes that break stuff in past big versions.
  2. the minor number represents changes that doesn't break stuff in past versions.
  3. the patch number represents bug fixes


Pretty easy to follow, right?

Practical Use

I recently released a web application called Infinite Memory. I wrote about it here. I decided to go ahead and slap on a version when I glanced in the sidebar on Github:


Easy enough, eh? Well, almost. When I entered some basic details for a v1.0.0-beta, it let me know that I needed a valid tag. What's this, you ask? Well, I didn't know either.


Git Tags

Turns out, in addition to commits, you can create tags with Git. These denote places in the code history where big things happened. Big things like...a version release! Makes total sense.

Here's an article on Git Tagging Basics. It seemed as straightforward as committing changes, so, I jumped back into VS Code to tag away. I wanted to tag the commit I made today, so I first grabbed my commit history: git log --pretty=oneline. Then I tagged it with: git tag -a v1.0.0-beta 63380025. I entered the first few digits from the checksum from my log to put the tag on the proper place.


Now it's tagged correctly, but sharing tags works differently than pushing changes in the codebase. If you run git status everything appears up to date.

Instead, I run

git push origin v1.0.0-beta

and, voila! Everything looks good from the terminal:


And sure enough, all is well on Github. I can now select my v1.0.0-beta tag to create my release! I also opted to select the pre-release box which marks it as a non-production piece of software.


I hope this was a helpful walkthrough for you! I enjoyed learning a little something new today, and I hope it was an enjoyable walkthrough for you as well!

Check out the actual release I worked on here!


I'd love if you said hi! Drop a comment below, or connect with me over on Twitter and/or LinkedIn.

Did you find this article valuable?

Support Eamonn Cottrell by becoming a sponsor. Any amount is appreciated!