Semantic versioning with tags in Git - Mini Project: Build & Apply

Semantic versioning with tags

📖 Scenario: You are working on a software project and want to keep track of your releases using semantic versioning tags in Git. Semantic versioning uses tags like v1.0.0, v1.1.0, and v2.0.0 to mark major, minor, and patch releases.

🎯 Goal: You will create a Git repository, add some commits, and then create semantic version tags to mark your releases. Finally, you will list the tags to see your version history.

📋 What You'll Learn

Initialize a Git repository

Create at least two commits

Create semantic version tags with exact names

List all tags to verify

💡 Why This Matters

🌍 Real World

Semantic versioning tags help developers and users know which version of the software they are using. This is important for tracking changes and compatibility.

💼 Career

Many software projects use Git tags for release management. Knowing how to create and manage semantic version tags is a key skill for developers and DevOps engineers.

1

Initialize Git repository and create first commit

Initialize a new Git repository using git init. Then create a file named README.md with the content "Project start". Add the file to Git and commit with the message "Initial commit".

Git

# Run the commands to initialize Git and create the first commit
# Your code here

Hint

Use git init to start the repo. Use echo to create the file. Then add and commit.

2

Create second commit with a new file

Create a file named app.py with the content "print('Hello World')". Add and commit this file with the message "Add app.py".

Git

git init

echo "Project start" > README.md

git add README.md

git commit -m "Initial commit"

# Create app.py with print statement, add and commit
# Your code here

Hint

Create the file with echo, then add and commit it.

3

Create semantic version tags

Create two tags: v1.0.0 for the first commit and v1.1.0 for the second commit. Use git tag with the exact tag names. Tag the commits in the order they were made.

Git

git init

echo "Project start" > README.md

git add README.md

git commit -m "Initial commit"

echo "print('Hello World')" > app.py

git add app.py

git commit -m "Add app.py"

# Create tag v1.0.0 for first commit
# Create tag v1.1.0 for second commit
# Your code here

Hint

Use HEAD~1 to tag the first commit and HEAD for the latest commit.

4

List all semantic version tags

Use git tag to list all tags in the repository. This will show your semantic version tags.

Git

git init

echo "Project start" > README.md

git add README.md

git commit -m "Initial commit"

echo "print('Hello World')" > app.py

git add app.py

git commit -m "Add app.py"

git tag v1.0.0 HEAD~1

git tag v1.1.0 HEAD

# List all tags
# Your code here

Hint

Just run git tag to see all tags.

Practice

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