How to Tag commits in the repository (Git)

Before we start, you must go to the jgit directory, where we made the original clone for this post.

We should start by tagging the commit that is ten commits behind origin/stable-2.3 and is not a merge. In order to find that commit, we will use the git log command.

Step 1 : Find the commit as follows:

git checkout stable-2.3 
git log -11 --no-merges --oneline

Step 2 : Now that we have found the 60d538f commit, we should make it a lightweight tag. Use the git tag command to give a meaningful release name:

git tag 'v2.3.0.201302061315rc1' ea060dd

Step 3 : To see whether the tag is available, use the git tag command:

git tag -l "v2.3.0.2*"

Step 4 : Our tag is available, but all it really says is that we have a tag in the repository with the name v2.3.0.201302061315rc1, and if you are using git show v2.3.0.201302061315rc1, you will see that the output is the same as git show ea060dd:

git show v2.3.0.201302061315rc1
git show ea060dd

Step 5 : There will also be a lot of file diff information in the output, but it is exactly the same output. So, in order to add more information, we should use an annotated tag. An annotated tag is a tag where you have to add some information to the tag. To create an annotated tag, we use the --annotate tag for the git tag command:

git tag --annotate -m "Release Maturity rate 97%" 'v2.3.0.201409022257rc2' 1c4ee41

Step 6 : The -m flag is the same as --message, as we want to give the tag a message. If you leave out the -m flag, Git will open the configured editor and you can write a full release note into the annotation of the tag. We can check the tag information with git show:

git show 'v2.3.0.201409022257rc2'

Step 7 : Tags are very powerful as they can add valuable information to the repository, and since tags should be considered official releases in the repository, we should be very careful when working with them. You can push the tags to a remote area, and contributors to the repository would fetch those tags. If you change a tag that you have already pushed to point to another commit hash, then those developers who have already fetched the tag will not get the new tag unless they delete the tag locally

Step 8: To prove the dangers of not getting a new tag, we will try to delete a tag and recreate it to point to another commit hash:

git tag -d v1.3.0.201202121842-rc4

Step 9 : Now that we have deleted the tag, we are ready to recreate the tag again to point to HEAD:

git tag -a -m "Local created tag" v1.3.0.201202121842-rc4

Step 10 :We have recreated the tag, and it points to HEAD because we did not specify a commit hash at the end of the command. Now, execute git fetch to see whether you can get the tag overwritten from the remote repository:

git fetch

Step 11 : Since there is no output, the tag was probably not overwritten. Let's verify with git show

git show v1.3.0.201202121842-rc4

Step 12 : As you can see from the output, it is still our locally created tag. To get the tag from the remote again, we need to delete the local tag and do a git fetch. To delete a tag, you need to apply the -d flag:

git tag -d v1.3.0.201202121842-rc4
git fetch

Step 13 : As you can see, Git has fetched the tag from the server again. We can verify with git show:

git show v1.3.0.201202121842-rc4

So, as you can see, we have the correct tag again, but it should also be a warning. Once you have pushed a tag to a remote repository, you should never change it, since the developers who are fetching from the repository may never know about the changes unless they clone again or delete the tags locally and fetch them again.