Semantic versioning with tags in Git - Step-by-Step Execution

Process Flow - Semantic versioning with tags

Start: Code changes ready

↓

Decide version bump: Major, Minor, Patch

↓

Create tag: vMAJOR.MINOR.PATCH

↓

Push tag to remote

↓

Tag used to mark release version

Semantic versioning tags mark releases with major, minor, and patch numbers to track changes clearly.

Execution Sample

Git

git tag v1.2.3

git push origin v1.2.3

Create a semantic version tag v1.2.3 and push it to the remote repository.

Process Table

Step	Command	Action	Result
1	git tag v1.2.3	Create a tag named v1.2.3	Tag v1.2.3 created locally
2	git push origin v1.2.3	Push the tag to remote repository	Tag v1.2.3 pushed to remote
3	git tag	List all tags	v1.2.3 shown in tag list
4	git show v1.2.3	Show commit details for tag	Commit info for tagged version displayed

💡 Tag v1.2.3 created and pushed successfully, marking the release version.

Status Tracker

Variable	Start	After Step 1	After Step 2	Final
Tags	none	v1.2.3 (local)	v1.2.3 (local + remote)	v1.2.3 (local + remote)

Key Moments - 3 Insights

Why do we use tags like v1.2.3 instead of just commit hashes?

Tags like v1.2.3 give a clear, human-friendly version number marking releases, unlike commit hashes which are long and not descriptive. See execution_table step 1 and 3.

What happens if I create a tag but don't push it?

The tag exists only on your local machine and others can't see it. Step 2 in execution_table shows pushing makes it available remotely.

How do I know which commit a tag points to?

Using 'git show <tag>' displays the commit details the tag references, as shown in step 4 of execution_table.

Visual Quiz - 3 Questions

Look at the execution table, what is the result after running 'git tag v1.2.3'?

A Tag deleted

B Tag pushed to remote

C Tag v1.2.3 created locally

D No tag created

💡 Hint

Check the 'Result' column in step 1 of the execution_table.

At which step is the tag pushed to the remote repository?

A Step 2

B Step 3

C Step 1

D Step 4

💡 Hint

Look at the 'Command' and 'Action' columns in the execution_table.

If you skip step 2, what will the 'Tags' variable show after step 3?

A v1.2.3 (local + remote)

B v1.2.3 (local only)

C No tags

D v1.2.3 deleted

💡 Hint

Refer to variable_tracker and the explanation in key_moments about pushing tags.

Concept Snapshot

Semantic versioning tags use format vMAJOR.MINOR.PATCH
Create tags with 'git tag vX.Y.Z'
Push tags with 'git push origin vX.Y.Z'
Tags mark release points clearly
Tags help track versions beyond commit hashes

Full Transcript

Semantic versioning with tags means marking your code releases with clear version numbers like v1.2.3. You create a tag locally using 'git tag v1.2.3' which points to a specific commit. Then you push this tag to the remote repository with 'git push origin v1.2.3' so others can see it. Tags help identify release versions easily instead of using long commit hashes. You can list tags with 'git tag' and see details with 'git show v1.2.3'. This process helps teams track and manage software versions clearly.

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