How do you use tags in git to manage software versions

Question

We use git to manage our project, we have a branch for each: dev staging production

I want to use git tags to manage versions of the software. As far as I can see if I am on a branch and add a few commits, I then have to run: git tag 1.0

Repacing 1.0 with whatever version number we are up to, then I can push the tag using: git push origin 1.0

And I can update the branch with: git push --tags

But how do I reuse a tag now? If I commit more code to my local repository and want it to be version 1.0 easily? Or do you just add a new tag like 1.1?

Also, what happens if my colleague uses the same tag name on his local repository and we both push the code for that same tag up?

Lastly, what happens if we accidentally push our code without running git tag to tag the commits.

I'm not really getting how tags work, I thought they would work like you would tag a blog post or something - you can tag lots of different commits with the same tag and reuse the tag etc. kind of like a branch I guess.

Answer 1

A great resource for tag info is on gitref.org

Don't try and reuse version numbers. Best is to just go to 1.1 or 1.0a. This is discussed at length in the man page.

For your question:

Lastly, what happens if we accidentally push our code without running git tag to tag the commits?

You can tag old commits by putting the commit ref in the command:

git tag 1.1 HEAD~3

Answer 2

I've had similar problem before. Here are two things I've found helpful:

• gitflow
• VonC's answer for my similar question

Answer 3

But how do I reuse a tag now? If I commit more code to my local repository and want it to be version 1.0 easily? Or do you just add a new tag like 1.1?

You can delete the tag with git tag -d 1.0, then delete it on the server with git push origin :refs/tags/1.0.

But the best practice is to only tag releases, and then create a maintenance branch for that release at the point where the tag is created. On that branch you push your fixes, and tag with 1.1, 1.2, ... as you make updated releases. It is bad practice to move a tag after you've given that code to a customer.

Also, what happens if my colleague uses the same tag name on his local repository and we both push the code for that same tag up?

I'm pretty sure the second one of you to push the tag will receive an error. Try it yourself to see what happens:

git checkout -b testbranch
git tag test1
git push origin tag test1
git tag -d test1
touch testfile
git add testfile
git commit -m "Added testfile"
git push origin testbranch
git tag test1
git push origin tag test1

Lastly, what happens if we accidentally push our code without running git tag to tag the commits.

You should push your tags after you've pushed the commits. You cannot do both at the same time (git push --tags does not push commits, only tags). If you push tags first, the remote will have dangling references until you push the commits. So you should be doing

git push origin master
git push origin --tags

or similar, depending on your situation.

I'm not really getting how tags work, I thought they would work like you would tag a blog post or something - you can tag lots of different commits with the same tag and reuse the tag etc. kind of like a branch I guess.

Tags are like labels on commits, so you can mark some commits as being 'special'. Most commonly, this is used to tag releases, so you can always go back and see exactly what was in that release if a customer reports a bug.