Practicing stability with git tag
I was stumbling and frustrated over the merging process when all of our dev codes got into staging. I was creating and deleting staging branch over and over again because one of dev branch was not working and basically it had to move over next release.
It was really a pain in the ass. Well, yes, seriously!
How many times had I created that staging branch?! I don’t even remember.
Frustrated enough, our team decided to use tags for staging branch.
Phew! Finally, I got some stable reversible codes from/to which I could switch to for deployments.
It’s all git tag. We created tags, pushed them, moved them whenever needed and made a stable staging deployment.
And here’s how tag helped us move smoothly over our dev process.
Creating a git tag
$ git tag <tag_name>These are light-weighted tags which basically doesn’t store any extra tag information.
Did I just say extra tag information?
Yes, you can create tags with other informations and it is called tag object which requires tag message.
Create annotated tag
Creating an annotated tag in Git is simple. The easiest way is to specify -a when you run the tag command:
$ git tag -a <tag_name> -m "Your tag description"The -m specifies a tagging message, which is stored with the tag. If you don’t specify a message for an annotated tag, Git launches your editor so you can type it in.
You can see the tag data along with the commit that was tagged by using the git show command:
$ git show v7.0
tag v7.0
Tagger: Kelina Shrestha <rocknumetal97@gmail.com>Version 7.0
Note: Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels.
What would you do if you forgot to create tags and moved on?
Well, it happened to us when we were releasing versions within two weeks and got no time to track releases in the repository.
But No worries.
You can tag them later by pointing it to your commit.
$ git tag -a <tag_name> <commit_id> -m "Your tag description"For e.g.
$ git tag -a v6.4 2623a62be -m "Version 6.4"Listing tags
To list all your git tags, you can just do:
$ git tagsToo many tags? Forgot the tag halfway?
You can search for tags that match a particular pattern.
$ git tag -l "v7.0*"
v7.0
v7.0-rc0
v7.0-rc1
v7.0-rc2
v7.0-rc3
v7.0.1
v7.0.2
v7.0.3
v7.0.4
v7.0.5v7.0.4v7.0.5
To see any specific tag, just type in.
$ git show <tag_name>This will show the exact commit where you created the tag.
Sharing tags
Now that we created tags, we need them on our servers as well.
By default, the git push command doesn’t transfer tags to remote servers. You will have to explicitly push tags to a shared server after you have created them.
$ git push origin <tag_name>If you have a lot of tags that you want to push up at once, you can also use the --tags option to the git push command. This will transfer all of your tags to the remote server that are not already there.
$ git push origin --tagsWhen someone else clones or pulls from your repository, they will get all your tags as well.
Once your tags are created, to mark stable versions, you can create releases in the repository.
You can do so by navigating to your Releases tab and create releases from tags by just clicking over dots on tag.
Re-tagging
What should you do when you tag a wrong commit and want to re-tag?
If you have never pushed them, just re-tag it.
$ git tag -a v6.4 3826b2e76But if you have pushed it, then the others will have already seen the old tag.
In that case, either create a new tag named as v6.4.1 or let others fetch the new tag after deleting the old one in their machines.
First, update tag and force pushed it.(not recommended though)
$ git tag -a v6.4 -m "Version 6.4" -f
Updated tag 'v6.4' (was 893f017)$ git push origin v6.4 -f
Let other know that you updated tags and let them fetch on their machines.
Tell them to hit these.
$ git tag -d v6.4$ git fetch origin v6.4
This might be no-no for your peers so be careful when pushing tags to your repository.
Checking out tags
If you want to view the versions of files a tag is pointing to, you can do a git checkout of that tag, although this puts your repository in “detached HEAD” state, which has some ill side effects.
$ git checkout <tag_name>$ git checkout v7.0.0
In “detached HEAD” state, if you make changes and then create a commit, the tag will stay the same, but your new commit won’t belong to any branch and will be unreachable, except by the exact commit hash. Thus, if you need to make changes — say you’re fixing a bug on an older version, for instance — you will generally want to create a branch.
$ git checkout -b version-7.1 v7.0.0
Switched to a new branch 'version-7.1'If you do this and make a commit, your version-7.1 branch will be slightly different than your v7.0.0 tag since it will move forward with your new changes, so do be careful.
Deleting tags
Tags can be over populated, especially in staging environment when changes are frequently happening.
To delete tag:
$ git tag -d <tag_name>This will delete the tag on your machine.
Don’t forget to delete tags on the repository if you have already pushed it!
Be careful though!
You are deleting tags on your repository so think twice before doing this!
$ git push --delete origin <tag_name>This, indeed saved a lot of time when switching to stable commits and deploying it in servers especially when you are merging all development branches and performing integration testing.
If you have the same tag name as the branch name, then you can simply delete just the tag with reference after deleting it on your local.
git push origin :refs/tags/<tag_name>Voila!
