Use of Git Tag & Git Bisect
Let’s get started… 👩💻
What is a Git tag?
Tagging in Git or any other version control system refers to creating specific points in the commit history for your repository/data. This is usually done to mark release point for e.g. Suppose, your project is stable and you want to mark as release-v1.0 then you can create the tag for that.
Why should I create a tag?
- To mark release points for your code/data.
- To create historic restore points
When to create a tag?
- When you want to create a release point for a stable version of your code.
- When you want to create a historic point for your code/data that you can refer at any future time (to restore your data).
Two Types of Git Tags
There are two types of tags in Git: annotated and lightweight. Both of them will allow you to refer to a specific commit in a repository, but they differ in the amount of metadata they can store.
- Annotated Tags
Annotated tags store extra metadata such as author-name, release notes, tag-message, and date as full objects in the Git database. All this data is important for a public release of your project.
Tags can also include a more descriptive tag-message or annotation much like a commit message when you are about to merge. Usually, this is achieved by using (-a for annotation).
git tag -a v1.0Executing this command you will create a new annotated tag identified with the version v1.0 . The command will then open up your commit editor so that you can fill up the metadata.
In case you wanted to add a tag-message you can pass the -m option, this is a method similar to git commit -m.
git tag -a v1.0 -m “Releasing version v1.0”- Lightweight Tags
Lightweight tags are the simplest way to add a tag to your git repository because they store only the hash of the commit they refer to. They are created with the absence of the -a, -s, or -m options and do not contain any extra information.
To create a new lightweight tag execute the following command:
git tag v1.0Now, Let’s dive into the example.
In our repository, we have two branches called master(default), api-login and we are currently in the master branch.
Let’s have a view of our commits in the master branch.
Now, let’s create an annotated tag.
In the above image, you can see the tag: v1.0 in our latest commit. The difference between the annotated and lightweight tag is that the annotated tag gives much more information about the tag such as tagger-name, creation date, tag-message, etc. To view, tag data use git show tag-name. See in the image below.
If you don’t specify the commit ID in the git tag command then it will apply the tag to the latest commit.
Now, Let’s add another tag in the api-login branch commits. For that, checkout to the api-login branch from git checkout command.
Here, I have used the lightweight tag with a commit-id. Let’s view the v1.0.0 tag data using git show tag-name command.
In the lightweight tag, we have author-name, creation date. The (-) sign in red color indicates the removed code and (+) sing in green color indicates the added code. In lightweight tag we missed is a tag-message which was in the annotated tag.
Listing Tags:
Use the command whenever you want to list all the existing tags, or you could filter the list with git tag -l ‘v1.*’, where * acts as a wildcard. It will return a list of tags marked with v1.0.
You will notice that when you call git tag you do not get to see the contents of your annotations. To preview them you must add -n to your command. Look at the image below.
Publishing tags — git push <location> <tag-name>
A tag is just a reference to your local repository and is not automatically pushed to the remote repository with the rest of the cod. Instead, you can git push the tag individually, or you can run git push — tags that will push all tags at once. It can be done similarly to pushing the branches.
git push origin v1.0
Let’s have a look at our remote repository.
As you see in the image above, we have a releases tab on Github in which our tags are created.
In this image, we have both tags v1.0 and v1.0.0 . Which also provides a feature to download the tags just by clicking on the zip. In simple words, we can define tags as a backup to our previous versions of our code.
Deleting tags — git tag -d <tag-name>
Generally, there is no reason to delete the tags because they are inexpensive and don’t use any resources unless you have mistakenly created a tag pointed to the wrong commit.
In case the tag has been already pushed and you need to remove it from remote repository use command git push origin :<tag-name> or git push origin -d <tag-name> .
To delete multiple tags at once:
git tag -d <tag-name1> <tag-name2> (local)
git push origin -d <tag-name1> <tag-name2> (remote)
How to discover a bug using git bisect
A git bisect is a tool that allows you to find an offending commit. Let’s say you’ve come across a bug in your codebase and you’re unsure of when it was introduced. If you can find a commit where the code works properly and a commit where it doesn’t, you don’t have to trace down the offending commit by hand; git bisect will do it for you.
Bisect comes from the binary search algorithm, and it’s an efficient way to search through a large set of (sorted) data. By repetitive dividing the batch in half and performing some kind of validation check, we are able to scan through a huge amount of data in a limited number of iterations. Bisect could be performed manually, by simply “checking out” to a specific commit and looking through the code. Yet the provided implementation protects us from all sorts of possible errors and does a lot of manual labor for us.
When it’s a good time to use bisect? When you are not exactly sure when a specific change had happened in the code. It may be a bug hard to track when it was introduced, unwanted change, like a code deletion that was mistakenly removed. In all those cases bisect comes in handy.
I always believe the best way to learn is to demonstrate.
for e.g: Firstly, Let’s view our commit history.
This is the view of our web page till now. 👇
When everything is working, when clicking on the Login button, the site will popup an alert message. However, when we clicked on it, nothing happens, but this was definitely working at some point!
So let’s start our search for the bad commit (For demonstration purpose our commit list is about 8 or so but in the real world, it can be hundreds or thousands!):
git bisect startThis starts the git bisect process, on our commit, the bug is present, so we need to designate it as a bad commit.
In our case, the good commit SHA is 71fa6bd and bad commit SHA is HEAD (cec2e02). Now, you might be thinking of how I came to know about good commit SHA. Well, my code works properly in the 71fa6bd commit SHA. To view the code in the 71fa6bd commit. Firstly checkout to that commit using git checkout <commit-id> after then run git show command.
The above diagram illustrates the bisecting of a bad commit. Git will bisect the commits between 71fa6bd and cec2e02 commits. 👇
Now, bisecting starts you’ll see git sending you the following message back.
git bisect automatically switches your code to the next commit in the list that it thinks contains the buggy commit. All you have to do is to refresh “form.html” and see if the bug is still there if it is then type git bisect bad, otherwise type git bisect good.
In 728317e commit-id, we found the error and mark as a bad commit. Again git bisect automatically switches to another commit which is 1e2bcbd.
Again we use the command git show to view the code in the 1e2bcbd commit-id which is a good commit. I’ have this commit as good.
We found our bad commit, it’s time to exit the bisect tool.
git bisect reset
After that, you can reset the buggy commit using git reset command or you can add create a new commit after fixed the error.
Pretty amazing isn’t it? Git Bisect shines, even more, when you have hundreds or thousands of commits to sift through!
I hope you find this blog useful. If you liked it then don’t forget to give a clap and share it with your friends.
Thanks.
