I know that tags exist, but I've never used them and I haven't met anyone who uses them yet, what are they used for?
From what it says in the Git documentation , it's a way to create a message history , parallel to the commit history to mark only the most important changes, is that it? does it have more uses?
Literally tag means tag .
Every time you commit, a unique identifier of the type is created
0dc20efa9ec36cefd67dcb832d9b01b7531c3a33, but even if you put a comment saying "This commit is the production version of D-day" , it's not an easy thing to look up, so you can create a tag to help you find it or get back to it quickly. If you created a tag at that time of type v1.0.0 , you can always do agit checkout v1.0.0and you'll get the code as it was.When you move to a tag it's like moving to a branch, but in detached mode : you can't modify the code and commit unless you create a branch because what you have is a snapshot , a snapshot of the code at a given time.
In addition, commits usually have as a comment what was changed in the code: a new functionality, a bug patch, an aesthetic change... etc. A tag can have as a comment information about the deployment, the list of changes since the previous version... in addition to the fact that the tag itself can already give you an idea (if you use semver ) of the changes that may be and the level of backward compatibility.
In addition to Pablo's answer, which is impeccable, it should be noted that when you publish a library in a package registry (npmjs in the case of node, packagist in the case of PHP) it would not be appropriate for the people who use your library to bring the #master branch every time you install.
Rather, your library will have a manifest (package.json for node, composer.json for PHP) that explicitly declares the version. And that version is associated with a repository tag.
When someone installs your library they can ask for a specific version (eg 0.9.2) and this is associated with a tag, because the idea is that if you ask for a specific version the code you receive is always the same.
Package registries usually cache versions of your library, so when someone installs it they don't have to hit GitHub (which limits bandwidth in that regard). This cache allows registries to keep a limited range of versions, which would not be practical if they had to cache every commit you make.
As a side effect, a tag published that way allows you to continue modifying the master branch without worrying about breaking something that was working the last time you saw it. That is: if your deployment flow of an application deploys not a branch but a tag to production, you are not going to harm the production environment by adding code to the branches.
It's worth noting that tags exist in a separate hierarchy than branches. The branches are designed to generate new features or patches and eventually re-integrate with master. A tag is not intended to interact to or from other tags or branches. For the same reason, you can have a million tags and managing your repo does not increase in difficulty. If you manage two dozen branches, however, it becomes unmanageable.
They serve to leave a record, a mark of a specific version. They are made when you release a version (v0.1, v1.0, v2.2, etc.) so that you can go back to that version in case you have to test any functionality or bug that happens in that version
Tag is applied as a GitFlow work methodology, the idea is to have the following branches
When you have a group of developers, they all work on different features, you must deliver everything developed to the client (this is known as a release), once the features have been unified in develop and they pass the tests, they are added to the master branch, generating a new tag .
Tags are more common than you think if you work in JavaScript you will notice
package.jsonthere is something like @angular/cli :what does it mean , bring me the repository in "
angular/cli" whose tag is "v7.1.0"If you want to know how to download a tag I invite you to read Download a specific tag from a git repository
To freeze final versions of the code, for example if you have released version 1.0 of it, you can generate a tag and users download that version.
In case of finding a bug in the tag code, a new branch must be created to correct it, later it is released and the tag cycle would be repeated.