Bird
Raised Fist0
Gitdevops~5 mins

Semantic versioning with tags in Git - Commands & Configuration

Choose your learning style10 modes available
LearnWhyDeepVisualTryChallengeProjectRecallTime

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Introduction
Semantic versioning helps you label your software versions clearly using numbers like 1.0.0. Git tags let you mark these versions in your project history so you can easily find or share them later.
When you want to mark a stable release of your project so others know which code is safe to use
When you need to track changes between versions with clear version numbers like 1.0.0, 1.1.0, or 2.0.0
When you want to share a specific version of your code with teammates or users
When you want to roll back to a previous version quickly if a new release has problems
When you want to automate deployment tools to use the latest tagged version
Commands
This command creates an annotated tag named v1.0.0 with a message describing the release. Annotated tags store extra info like the tagger's name and date.
Terminal
git tag -a v1.0.0 -m "Release version 1.0.0"
Expected OutputExpected
No output (command runs silently)
→
-a - Creates an annotated tag
→
-m - Adds a message to the tag
This command pushes the tag v1.0.0 to the remote repository so others can see and use this version.
Terminal
git push origin v1.0.0
Expected OutputExpected
Total 0 (delta 0), reused 0 (delta 0) To https://github.com/username/repo.git * [new tag] v1.0.0 -> v1.0.0
This command lists all tags in your local repository so you can see all version labels you have created.
Terminal
git tag
Expected OutputExpected
v1.0.0
This command switches your working directory to the code state at the tag v1.0.0, letting you view or use that exact version.
Terminal
git checkout v1.0.0
Expected OutputExpected
Note: switching to 'v1.0.0'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. HEAD is now at abc1234 Commit message for v1.0.0
Key Concept

If you remember nothing else from this pattern, remember: semantic version tags in git let you mark and share exact versions of your code clearly and safely.

Common Mistakes
Creating lightweight tags instead of annotated tags
Lightweight tags do not store extra information like who created the tag or when, making them less useful for releases.
Always use 'git tag -a' with a message for release versions to create annotated tags.
Not pushing tags to the remote repository
Tags stay only in your local repository and others cannot see or use them until pushed.
Use 'git push origin <tagname>' to share tags with others.
Using inconsistent tag naming without semantic versioning format
It becomes hard to understand the order and meaning of versions without a clear pattern like MAJOR.MINOR.PATCH.
Follow semantic versioning format like v1.0.0, v1.1.0, v2.0.0 for clarity.
Summary
Use 'git tag -a v1.0.0 -m "message"' to create an annotated semantic version tag.
Push tags to remote with 'git push origin v1.0.0' so others can access them.
List tags with 'git tag' and checkout a version with 'git checkout v1.0.0' to use that code state.

Practice

(1/5)
1. What does the PATCH number represent in semantic versioning like 1.4.2?
easy
A. Build metadata or pre-release information
B. New features added in a backward-compatible way
C. Major changes that break backward compatibility
D. Bug fixes and small changes that do not affect the API

Solution

  1. Step 1: Understand semantic versioning parts

    Semantic versioning uses MAJOR.MINOR.PATCH format where PATCH is the last number.

  2. Step 2: Identify PATCH meaning

    PATCH is for bug fixes or small improvements that do not change the API or features.

  3. Final Answer:

    Bug fixes and small changes that do not affect the API -> Option D

  4. Quick Check:

    PATCH = bug fixes [OK]
Hint: PATCH fixes bugs without changing features [OK]
Common Mistakes:
  • Confusing PATCH with MINOR or MAJOR
  • Thinking PATCH adds new features
  • Mixing PATCH with build metadata
2. Which git command correctly creates an annotated tag named v2.1.0 with a message?
easy
A. git tag -a v2.1.0 -m "Release version 2.1.0"
B. git tag v2.1.0 -m "Release version 2.1.0"
C. git tag -m "Release version 2.1.0" v2.1.0
D. git tag --message v2.1.0 "Release version 2.1.0"

Solution

  1. Step 1: Recall annotated tag syntax

    Annotated tags use -a and -m for message: git tag -a tagname -m "message".

  2. Step 2: Match correct command

    git tag -a v2.1.0 -m "Release version 2.1.0" matches this syntax exactly, others misuse flags or order.

  3. Final Answer:

    git tag -a v2.1.0 -m "Release version 2.1.0" -> Option A

  4. Quick Check:

    Annotated tag = git tag -a -m [OK]
Hint: Use -a and -m together for annotated tags [OK]
Common Mistakes:
  • Omitting -a for annotated tags
  • Placing -m before tag name incorrectly
  • Using --message instead of -m
3. Given these git tags: v1.0.0, v1.2.0, v1.2.3, what will git describe --tags output if the current commit is exactly at v1.2.3?
medium
A. v1.2.3
B. v1.2.3-0-g
C. v1.2.0
D. v1.2.3-1-g

Solution

  1. Step 1: Understand git describe output

    If the current commit matches a tag exactly, git describe --tags outputs just that tag name.

  2. Step 2: Apply to given tags

    Since current commit is exactly at v1.2.3, output is v1.2.3 without extra suffix.

  3. Final Answer:

    v1.2.3 -> Option A

  4. Quick Check:

    Exact tag commit = tag name only [OK]
Hint: Exact tag commit shows tag name only [OK]
Common Mistakes:
  • Expecting extra suffix even on exact tag
  • Confusing closest previous tag with current
  • Misunderstanding commit hash suffix
4. You tried to create an annotated tag with git tag -m "Release 1.0" v1.0.0 but it created a lightweight tag instead. What is the error?
medium
A. Using double quotes instead of single quotes for message
B. Incorrect order of arguments; message must come after tag name
C. Missing -a flag to create an annotated tag
D. Tag name v1.0.0 is invalid

Solution

  1. Step 1: Check command syntax for annotated tags

    Annotated tags require -a flag; -m alone creates lightweight tag with message ignored.

  2. Step 2: Identify missing flag

    The command lacks -a, so it made a lightweight tag instead of annotated.

  3. Final Answer:

    Missing -a flag to create an annotated tag -> Option C

  4. Quick Check:

    Annotated tag needs -a flag [OK]
Hint: Always use -a for annotated tags [OK]
Common Mistakes:
  • Omitting -a flag
  • Thinking -m alone creates annotated tag
  • Confusing argument order
5. You want to tag a release as v3.0.0 but only if the current commit is ahead of v2.9.9 by at least one commit. Which sequence of commands correctly checks this and creates an annotated tag if true?
hard
A. git describe --tags --match "v2.9.9" && git tag -a v3.0.0 -m "Release v3.0.0"
B. if [ $(git rev-list v2.9.9..HEAD --count) -gt 0 ]; then git tag -a v3.0.0 -m "Release v3.0.0"; fi
C. git tag -a v3.0.0 -m "Release v3.0.0" && git rev-list v2.9.9..HEAD --count
D. git tag v3.0.0 && git rev-list --count v2.9.9..HEAD

Solution

  1. Step 1: Check commits ahead of v2.9.9

    Use git rev-list v2.9.9..HEAD --count to count commits ahead.

  2. Step 2: Conditional tag creation

    If count is greater than 0, create annotated tag with git tag -a v3.0.0 -m "Release v3.0.0".

  3. Final Answer:

    if [ $(git rev-list v2.9.9..HEAD --count) -gt 0 ]; then git tag -a v3.0.0 -m "Release v3.0.0"; fi -> Option B

  4. Quick Check:

    Count commits then tag if ahead [OK]
Hint: Count commits ahead before tagging [OK]
Common Mistakes:
  • Tagging without checking commit count
  • Using git describe incorrectly for this check
  • Creating lightweight tag instead of annotated