Learn how to use Git Tag. Tags are a way of labeling states of your repository, commonly used to indicate the versions or releases of a project maintained with Git.
Git has the possibility of marking important states in the life of a repository, something that is usually used to manage the releases of a project. Through the “git tag” command we can create tags, in an operation commonly known as “tagging”. It is an operation that has many variants and utilities, we will see the most common ones that we are sure you will like to know.
In addition to keeping project code users and other developers informed of an application’s versions, tagging is an essential tool for letting other systems know when a project has changed and allowing themselves to trigger processes to run whenever this happens. . It’s actually important because some package managers force you to use it in order to publish packages to them. So, we are going to describe the bases for working with the tagging system so that you can use it in your day-to-day work with Git.
Version numbering
Git is a version control system. Therefore, it allows you to maintain all the states through which any of your files has passed. When we talk about a Git tag, we are not referring to the version of a particular file, but to the entire project as a whole. It is used to tag the state of the entire repository, something that is usually done every time a new version of the software is released.
Project versions are defined by the developer, but creating them arbitrarily is not recommended. Actually, the recommendation would be to give it a semantic value. This has nothing to do with Git, but we’re mentioning it here because it’s something we think it’s worth knowing when you start managing your versions in projects.
Changes can generally be divided into three levels of “importance”: Major, Minor, and Small Adjustment. If your project version was 0.0.1 and you make a change that does not alter the functionality or the work interface, then it is appropriate to version your application as 0.0.2. If the project already has some functionality extension, but still maintains full compatibility with the previous version, then we will have to increase the number in between, for example going from 1.0.0 to 1.1.0. Now, if the changes introduced in the project are such that they imply an alteration on how that application will be used, making it not completely backward compatible with previous versions, then the version should be increased by 1 in its most relevant number, for example, pass from 1.1.5 to 2.0.0.
The issue of semantics really matters little now, because we want to talk about Git. However, you will find it very well explained in this document, so if you are interested in the subject, we recommend you read it.
Create a tag with Git
When you start with a repository, it’s assumed that you don’t have any version numbering and tags, so we’ll start by looking at how they’re created.
Suppose we start with the version number 0.0.1. So to create the corresponding tag you will run the Git subcommand “git tag”:
git tag v0.0.1 -m “First version”
As you can see, it is a way to label repository states, in this case to define version numbers. You accompany them with a message, just as messages are sent in the commit.
Note: This is the mechanism known as “Lightweight Tagging”, there are other types of tagging that can be done using Git.
Generally, after making changes to your repository and pushing them to the system (after committing), you will be able to generate another version number tagging the current state.
git tag v0.0.2 -m “Second version, minor changes”
View version statuses in the repository with Git tag
After you’ve created your first tag, you can run the “git tag” command, just without any further parameters, which will tell you about the versions you’ve tagged so far.
git tag
If you have a repository where you’ve tagged three version numbers already, it might return output like the one you see in the image below.
Another interesting command in the topic of versioning is “show” that allows you to see how the repository was in each state that you have previously tagged, that is, in each version.
git show v0.0.2
You will receive a message similar to this as output:
tag v0.0.2 Tagger: Miguel Angel Alvarez
Push tags to GitHub
If you want your locally created tags to be pushable to the GitHub repository, you can trigger the push with the –tags option. This is mandatory, because if you don’t put it, the push command will not send the newly created tags.
git push –tags
Specifically, the –tags option, as we have used it, sends all the new tags created, although you could also send a specific one by specifying the one you want to send, as can be seen in the following command.
git push origin v0.0.4
In this case we must specify which remote repository is the destination of the tags that we have just created (“origin” in this case), because if the command is not specified it will understand that the name of our tag is the name of the remote repository that we are wanting. use to commit the local changes, which will give us an error.
Note: The –tag option appears to have the same effect as –tags. Both send the tags that we have locally to the remote repository. So you can try using both, although the Git documentation always uses –tags. git push –tag
Send tags and push commits at the same time
Just a little detail regarding the push command when we use it to send tags. When we use the –tags option in the push command, in principle the changes that we have in the repository are not sent. That is, even if we have made changes in the master branch and the corresponding commits have been made locally, if we launch “git push –tags”, only the new tags will be sent remotely. Commits that may have been made on any branch will not be pushed.
If we want to push a specific branch, for example the master branch, and push the tags at the same time, then we could run the following command.
git push origin master –tags
Git Tag Conclusion
In addition, in the case of GitHub you can also create tags in the repositories directly from the web interface of the service. From the main page of the repository, in the link that says “releases”, you can access information about the versions tagged in your project, as well as tag new versions.
We’ve learned how to tag project states with Git, which is commonly done to report to the version control system of major releases throughout the life of a software.
Working with Git Tag as you have seen is not complicated at all, since in principle there are only a couple of new commands that you have to learn. You can get more help on options for the git tag command with “git tag -h”.
We are sure that with this information you will have enough to start, but if you have any questions you can consult this .
Facebook Comments
Disqus