Why should I use tags vs. release/beta branches for versioning?

I've been using git for about a year and would like to use tagging to, well, tag commits at different versions. I've found lots of info on the commands to use to work with tags, but what I'd like to know is why use tagging at all if I can just create a new branch called 1.1.0 and not have to cloud my mind with a whole new set of git commands?

There has to be a lot of good reasons for tagging rather than branching but I'd like to know what those advantages are.

A tag is immutable.

Whereas you can create a branch named "1.0.0" - you, or anyone with commit rights, can also then simply push to that branch (deliberately or not) and change what 1.0.0 means.

You can't do that with a tag, once you create a tag - that's it; Tag 1.0.0 means exactly that and can't be changed^*.

That's the main practical difference between a tag and a branch

^* You can delete and recreate a tag thereby changing a tag, but certainly not by accident.

Tags are mainly used for future reference to the specific version of the project, by tagging a commit. You can always use branches of course, but if you change versions a lot, you will end up with lots of unused or rarely used branches.

Practically, tags are branches without branches anyway, just adding a way to reference a specific version of the project to reduce complexity.

Edit: Here is a nice way to use git that I use for all my projects.

Branch and tag are the same thing (pointer to a commit, aka. "ref"), except branch automatically moves to the next commit while tag stays forever¹ on the same commit.

When making a release, you generally want to mark the "snapshot" of the code from which that release was built, and you want it to stay marked that way even as you continue to evolve the code, so you'd use a tag.

If you tried using a branch for that, it could inadvertently move to a different commit, from which the release was not built.

---

¹ Unless you delete the tag, of course.

NOTE: I realize this is an old question, but I felt that the similarity (and one crucial difference) between branches and tags has not been fleshed out in other answers as clearly as it could have been.

I tend to use a workflow that incorporates both tags and branches. Tags are good for marking released code or notable development builds. Branches are good for keeping track of all changes relevant to a specific version.

Here's a good writeup on this type of workflow: http://nvie.com/posts/a-successful-git-branching-model/

You use tags to note important commits in history. "This was the exact commit we used for this version on that rainy thursday when the build server broke". If you use a branch instead of a tag, you can never know what exact commit you used. You only know "We released version 1.1.0 somewhere on this branch", unless you manually write down the exact hash for that commit, which is why you use tags in the first place :)

In addition to the other answers, here is my 2 cents.

Short Answer: Use tags for release versions

Long Answer: I believe using tags for release versioning specifically is better than using branches. If you need to update the relase, simply branch off of the tagged commit and once you finish working on that branch (most likely a hotfix branch), create a new tag at the head of that new branch with the new version. Then, merge that branch back into master/develop because you really shouldn't be changing a release version unless it's a hotfix that likely should be merged back into your source code. Then delete that branch since it's no longer needed. If you need to apply another hotfix to that new version, repeat the same steps.

Refer to the section of the following article that shows how to merge a hotfix with the author's Git workflow - https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2