Tags are a simple aspect of Git, they allow you to identify specific release versions of your code. You can think of a tag as a branch that doesn't...
For further actions, you may consider blocking this person and/or reporting abuse
Recently I gave a demonstration on "Tagging Releases in Git" in my organization. We short of implemented feature branching, and then I found having multiple long lived branches are nightmare.
Tagging for the version management is the best option, however I was not very confident, but after reading this article I think we are heading towards right direction.
Thank you, keep up the good work.
Wouldn't it be great that you share it on dev.to and have you own article published? Sharing is caring isn't it @arkaprovob
Okay, we know now how to create tags. But why do we want to do that ? Who is using these tags we created ? And what do they do with these tags ? Thanks !
Anyone wants to switch to a specific version can do it easily with tags (
git checkout v1.2.3 -b v1.2.3
)Tags are used for package-management (i.e. composer for PHP) and allow many automated tasks from testing to deployment where manual steps are not required anymore or minimized to the least amount of individual work. It's possible to do those things with "dev-main" too but that's an undefined and usually just most recent version, so it's not easily reproduceable if something is changed by further commits.
Nesha, nice article. My summary of lightweight tags versus annotated, is that annotated tags are more suitable for enterprise code releases due to the formality of having commiter's user name and date. Perhaps a lone developer working in the wild can get by just fine by lightweight tagging releases.
Cheers and thank,
Lancer
Thanks!
thanks bro
Do you tag before the commit bumping the version, or after it?
Should be done after.