I've been trying to figure out the best way to handle tagging repositories when releasing code, but I'm running into a few issues. First off, how do I tag a specific commit? Is it done through the git command line, through a web interface, or do some people set up automated jobs for this? Also, what should I do about old tags? In my experience with CI/CD tools, there's been a build per branch, which means we'd end up with a long list of tags and jobs that need tidying up—do people usually just ignore them and clean them manually? For context, where I've worked before, we either followed a convoluted git flow for the 'safety' or just released straight from the main branch, trusting that commits pushed there were safe. If you tag for releases, how do you manage these things? How often do you do releases, and who's responsible for them?
1 Answer
In my past jobs, we just tagged the master branch when ready for a release, which would trigger a pipeline to build and push the code. We didn't bother cleaning up old tags either; they’re just like logs that don’t use resources. Most of the tagging was automated through a Slackbot combined with AWS API, making it seamless. The release happened weekly for major updates, and hotfixes could happen anytime. Now, at a new place that uses GitHub Actions, the process varies a bit but is similar, and we tend to have releases every two weeks with no hotfixes. It sounds a bit confusing but once you get used to it, it’s straightforward!
Thanks for the insight! I think I’ve been overcomplicating things. It sounds like it really boils down to having a solid process in place.