Add new commit to the existing Git tag

Question

I have created a Git tag as v1.1 using

git tag -a v1.1 -m 'my version 1.1'

and I pushed that tag. Later, I made some changes related to v1.1. Now when I push new changes and check the git tag using git describe it is showing me v1.1-g2dcc97.

How can I add my new commit to the existing tag?

Answer 1

See disclaimer below.

Changing an annotated tag to another commit means making a new tag object and pointing it to that commit. This is the easiest way to do it:

git tag --force --edit <tag> [commit]

Now you get to keep the the tag message (just save immediately if you don’t want to change it). Which you don’t get if you delete and recreate the annotated tag.

The --edit above implies -a (annotated). To change a lightweight tag:

git tag --force <tag> [commit]

Disclaimer

You can make mistakes when making a tag. It makes sense to change the tag if you haven’t pushed it to anyone else yet. But in this case it might be misguided. You aren’t supposed to update tags as a matter of course. They are supposed to be immutable. But this is workflow dependent.

See “On Re-tagging” in man git tag. [1] The intended use of annotated tags is:

1. To be globally unique (built-in since refs are unique)
2. To be immutable

The intent is for other people to have a stable name for a given commit. This was centered around the Linux Kernel project. You can imagine the confusion that would happen if some central Linux maintainer published a tag and then changed it afterwards.

Changing a tag in this context is a headache for everyone.

1. People who fetch the old tag will keep it in their repository
   • Subsequent fetches will not update the tag. It will be kept as-is (see the aforementioned man page section). This is more or less a security feature.
2. In turn the maintainer has to make a public announcement to all who might have fetched the tag (could be the whole world?) and ask them to manually update the tag in their own repository

Tips

You can make Git log all tag updates:

git config set --global core.logAllRefUpdates always

... However you cannot use git-reflog(1) to view the ref updates (since they are annotated tags apparently, not commits). You have to manually look in the file:

$(git rev-parse --git-dir)/logs/refs/tags/<tag>

Notes

1. git version 2.48.1
2. See point № 1. The set syntax is relatively recent.

Answer 2

If you absolutely need to "move" the tag instead of creating a new one, You can do this:

NB: As @Chris said, make sure you have a good reason for not wanting to create a new tag because the best practice is to create a new one

1. Checkout the tag (a Detached HEAD)

git checkout tags/v1.1

2. Create and Checkout a branch off that tag (i.e. Branching off the tag)

git checkout -b my-tagged-branch

*** do work and commit changes ***

3. Push to the remote branch.

git push  -u origin my-tagged-branch

If needed merge branch into other branches that need the change (in case of a bug fix for example)

4. While still on my-tagged-branch, Delete the tag

git tag -d v1.1

5. Create the tag again: This will "move" the tag to point to your latest commit on that branch

git tag v1.1

6. Delete the tag on remote

git push origin :v1.1

7. Create the tag on remote

git push origin v1.1

Answer 3

I think many people believe that tags mean that multiple commits can have the same tag (how tags usually work). Like adding a tag to make a certain type of commit (ex: prod?) Well, in git, a tag is unique to a commit.

However, if you really want to use a tag you already used before you will need to delete it from remote and local and recreate it. But you should not want to do this...

//remove remote tag
git push origin :tag_name

//remove tag from local
git tag -d tag_name

//add tag to latest commit
git tag tag_name

git log

git push origin tag_name

Answer 4

You can't put a new commit into an existing tag without breaking an important Git guideline: Never(*) modify commits that you have published.

Tags in Git aren't meant to be mutable. Once you push a tag out there, leave it alone.

You can, however, add some changes on top of v1.1 and release something like v1.1.1 or v1.2. One way of doing that would be

# Create a new branch from tag v1.1
git checkout -b newbranch v1.1

# Do some work and commit it

# Create a new tag from your work
git tag -a -m "Tag version 1.1.1, a bugfix release" v1.1.1

(*) Unless you have a really super special reason for doing so, and only if you completely understand the implications, and even then, don't make a habit of it.