How to Check If a Git Commit Is Part of a Tag

Introduction

In this lab, you will learn how to determine if a specific Git commit is included in any of your project's tags. This is a valuable skill for understanding which releases or versions contain particular changes.

Through hands-on exercises, you will utilize the git tag --contains command to identify tags associated with a given commit and explore the functionality of git describe for checking tags. You will also test these methods with untagged commits to solidify your understanding.

Skills Graph

Run git tag --contains Commit

In this step, we will learn how to use the git tag --contains command to find which tags contain a specific commit. This is useful when you want to know which releases or versions of your project include a particular change.

First, let's make sure we are in our project directory. Open your terminal and navigate to the my-time-machine directory:

cd ~/project/my-time-machine

Now, let's create a few commits and tags to work with. We'll add a new file and make a commit:

echo "Another message for the future" > message2.txt
git add message2.txt
git commit -m "Add a second message"

You should see output similar to this:

[master <commit-hash>] Add a second message
 1 file changed, 1 insertion(+)
 create mode 100644 message2.txt

Now, let's add a tag to this commit. We'll call it v1.0:

git tag v1.0

This command doesn't produce any output, but it has created a tag pointing to the latest commit.

Let's make another commit without a tag:

echo "A third message" > message3.txt
git add message3.txt
git commit -m "Add a third message"

You should see output similar to this:

[master <commit-hash>] Add a third message
 1 file changed, 1 insertion(+)
 create mode 100644 message3.txt

Now we have two commits and one tag. Let's use git log --oneline to see our commit history:

git log --oneline

You should see something like this (commit hashes will be different):

<commit-hash> (HEAD -> master) Add a third message
<commit-hash> (tag: v1.0) Add a second message
<commit-hash> Send a message to the future

Notice that the v1.0 tag is associated with the "Add a second message" commit.

Now, let's find which tags contain the commit "Add a second message". We need the commit hash for this. From the git log --oneline output, copy the commit hash next to (tag: v1.0).

Replace <commit-hash> with the actual hash you copied and run the following command:

git tag --contains <commit-hash>

You should see v1.0 in the output, because this tag points directly to that commit.

Now, let's try to find which tags contain the first commit ("Send a message to the future"). Copy the commit hash for that commit from git log --oneline.

Replace <first-commit-hash> with the actual hash and run:

git tag --contains <first-commit-hash>

You should still see v1.0 in the output. This is because v1.0 is on a commit that is a descendant of the first commit. The --contains flag checks if the specified commit is an ancestor of the commit that the tag points to.

This command is very helpful when you need to determine which versions of your software include a specific bug fix or feature.

Use git describe to Check Tags

In this step, we will explore the git describe command. This command is used to find the most recent tag that is reachable from a commit. It's particularly useful for generating human-readable names for commits, especially those that are not directly tagged.

Make sure you are still in the ~/project/my-time-machine directory.

First, let's run git describe without any arguments:

git describe

Since our latest commit is not tagged, git describe will look for the nearest tag and then tell us how many commits have been made since that tag and provide a short version of the latest commit's hash. You should see output similar to this:

v1.0-1-g<commit-hash>

Let's break down this output:

• v1.0: This is the most recent tag that is an ancestor of the current commit.
• 1: This indicates that there is 1 commit between the v1.0 tag and the current commit.
• g<commit-hash>: The g stands for "git" and <commit-hash> is a short, unique identifier for the current commit.

This format is very useful for identifying specific builds or versions of your project, even if they don't correspond exactly to a tag.

Now, let's try running git describe on the commit that has the v1.0 tag. We need the commit hash for the "Add a second message" commit. You can get this from git log --oneline.

Replace <commit-hash-of-v1.0> with the actual hash and run:

git describe <commit-hash-of-v1.0>

This time, the output should simply be:

v1.0

This is because the specified commit is directly tagged with v1.0. When the commit itself is tagged, git describe just outputs the tag name.

The git describe command is a powerful tool for understanding the relationship between your commits and your tags, providing a concise way to name commits based on their proximity to the nearest tag.

Test Untagged Commits

In this step, we will further explore how git describe behaves with commits that are not directly tagged. This will reinforce your understanding of how it finds the nearest tag.

Ensure you are in the ~/project/my-time-machine directory.

We currently have a commit after the v1.0 tag. Let's make another commit:

echo "Yet another message" > message4.txt
git add message4.txt
git commit -m "Add a fourth message"

You should see output similar to this:

[master <commit-hash>] Add a fourth message
 1 file changed, 1 insertion(+)
 create mode 100644 message4.txt

Now, let's run git describe again:

git describe

This time, the output should be similar to:

v1.0-2-g<commit-hash>

Notice that the number between v1.0 and the commit hash is now 2. This is because there are now two commits on the master branch since the v1.0 tag was created. git describe correctly counts the number of commits from the tagged commit to the current commit.

This behavior is very useful in continuous integration and deployment pipelines, where you might want to automatically generate version names for builds based on the latest tag and the number of commits since that tag.

Let's try one more thing. We will create a new branch and make a commit on that branch.

git checkout -b feature/new-feature
echo "Feature file" > feature.txt
git add feature.txt
git commit -m "Add feature file"

You should see output similar to this:

Switched to a new branch 'feature/new-feature'
[feature/new-feature <commit-hash>] Add feature file
 1 file changed, 1 insertion(+)
 create mode 100644 feature.txt

Now, run git describe on this new branch:

git describe

The output should still be based on the v1.0 tag, but the commit count and hash will be different:

v1.0-3-g<commit-hash>

Even though we are on a different branch, git describe still finds the nearest reachable tag, which is v1.0 in this case. The commit count 3 reflects the number of commits from the v1.0 tag to the current commit on the feature/new-feature branch (the two commits on master plus the one on the feature branch).

This demonstrates how git describe works across branches, always finding the closest tag in the commit history.

Summary

In this lab, we learned how to check if a Git commit is part of a tag using two primary methods. First, we explored the git tag --contains <commit-hash> command, which directly lists all tags that include the specified commit. This is particularly useful for identifying which releases or versions incorporate a specific change. We practiced this by creating commits and tags, then using git log --oneline to obtain commit hashes and subsequently querying with git tag --contains.

Secondly, we briefly touched upon using git describe as another way to relate commits to tags, although the detailed steps for this were not fully provided in the excerpt. The lab also included a step to test untagged commits, reinforcing the understanding of how these commands behave when a commit is not associated with any tag. Overall, the lab provided practical experience in using Git commands to navigate and understand the relationship between commits and tags within a project's history.