Git tagging is that one great rule everyone knows about, but rarely practice.

Let me tell my experiences with Projspace release mechanism. Without being aware of it, I use to tag every release right from the very beginning. I realize now that these tags helped me in many critical situations.

Last week we were doing feature updates to Projspace and simultaneously, a lot of releases on production. Some with the feature updates and others with back-end architectural changes using Sidekiq etc. And the old familiar story of code not working in production was repeated and became our regular nightmare for a week.

Working on dev, not on prod

But our habit of tagging releases made the releases so clean that there was close to zero downtime, and the end users never faced any problems. We’ve been executing our releases during the night time, and when we encountered disasters, we immediately rolled back to the previously tagged release in a minutes time. Keeping with the best practices of tagging will save a lot of time, effort and most importantly avoid downtime.

I am sure many of those who are reading this already know this but very few might implement it.

Git Tagging Best Practices

  • Start with a minor version like 0.1.
  • Increment the versions with more decimal digits, if it is an improvement in the feature, e.g. 0.1.1.
  • Choose a major version if you are introducing an altogether new set of features like 0.2.
  • Bump it to an integer if you do significant architectural changes or going to public in a big way, e.g. 1.0.
  • Repeat the cycle and you will have a bunch of tags.
  • Use annotated tags. They help in identifying the person who tagged so that we can communicate with them.

I am sure your life will be lot easier if you follow these simple steps of tagging in a project.

If you are interested to see the tagging pattern of Projspace, here it is.

Git tagging for Projspace

This article was originally published April 22, 2014. It has been updated since then for clarity.