Practical Git: Use semantic versioning with git tag
Using git tag we can create references to commits that are immutable; this is usually used for making public releases. In this lesson, we show how to use git tag and go over common Semantic Versioning (AKA semver) conventions.
[00:00] In our command line, we're inside of a directory called utility functions, which is a Git repository. Let's run the git tag command, and we will use V1.00If we run the git tag command by itself, we can see that our repository has a tag.
[00:18] What happened here is we created a tag with the label V1.00Then when we run git tag by itself, it outputs all of the tags in the repo, which for us is just this one tag. The purpose of a git tag is to create a reference to a commit that can't be changed. Although you could theoretically put any label here, most people use git tags for versioning for specific releases.
[00:43] This labeling convention is common. It's called semantic versioning. It is three numbers separated by dots, where the first number is incremented when you have a major release with breaking code changes.The second number is for incrementing when you have a minor release, which is a minor feature that is not breaking. The third number is for incrementing when you have a patch release, which is a small bug fix. Again, that's major, minor, and patch.
[01:12] Let's assume we've added more features and fixed bugs in our project. We've introduced a breaking change. Let's run git tag, and we'll say V2.00Then we can run git tag again to check and make sure that tag got created correctly.
[01:28] If we want those tags to exist on our remote repository as well, we need to run the git push command with the tags flag. This shows us that we've added new tags to our remote repository.
[01:40] We can also use annotated tags to add notes to our tags. We do that by using the -a option, which stands for annotate, and then we provide our label as normal. In this case, let's say we fixed a bug. We'll bump the patch number, and now we can provide a message just like we would with a git commit.
[01:57] One thing that's nice is if you remove this message option, it will open up your default code editor to let you write more detailed release notes. I'll run this, and now we could have release notes in here specifying everything that's happened in this release.