Git Tags and Release Management

# CHAPTER 13

Git Tags and Release Management #

1. Introduction #

2. Learning Objectives #

• Define the operational concept of a Git Tag.

• Differentiate between Lightweight Tags and Annotated Tags.

• Create, list, and delete Annotated Tags.

• Push tags to remote repositories securely.

• Understand and implement Semantic Versioning (SemVer) principles.

3. Beginner-to-Advanced Explanations #

The Solution (Tags): A Tag is a permanent bookmark attached to a specific commit hash. Unlike a branch pointer (which constantly moves forward every time you commit), a Tag pointer is frozen in time. It will point to a1b2c3d forever. You simply command Git: git tag v1.0 a1b2c3d. Now, whenever you need to see Version 1.0, you just type git checkout v1.0.

4. Lightweight vs. Annotated Tags #

1. 1. Lightweight Tags:

   git tag v1.0-wip
   ```

2. **Annotated Tags:**
   This creates a full Git Object in the database (just like a commit). It stores the tagger's name, the email, the date, and a custom message. They can even be cryptographically signed with GPG for security. This is the **industry standard** for official releases.
   ```bash
   # Use the -a flag for annotated, and -m for the message
   git tag -a v1.0 -m "Official Release Version 1.0"
   ```

### 5. Semantic Versioning (SemVer)
Professional tags do not use random names like `tag-release-final-v2`. They adhere to a strict numbering convention known as Semantic Versioning: **MAJOR.MINOR.PATCH** (e.g., `v2.4.1`).

- **PATCH (`v2.4.1` -> `v2.4.2`):** You fixed a bug. The code functions exactly the same, it just works better now.
- **MINOR (`v2.4.1` -> `v2.5.0`):** You added a brand new feature (like a new API endpoint). Existing code still works perfectly.
- **MAJOR (`v2.4.1` -> `v3.0.0`):** You changed the core architecture. If a user upgrades to this version, their existing code might break.

### 6. Mini Project: Create Software Release Workflow
Let's simulate finalizing a software release and pushing the tag.

**Step-by-Step Walkthrough:**
1. Create a repository: `mkdir release-demo && cd release-demo && git init`
2. Create base code: `echo "V1 Code" > index.html && git add . && git commit -m "Complete Version 1 features"`
3. **Create the Tag:** This is the moment of release.
   ```bash
   git tag -a v1.0.0 -m "Initial Production Release"
   ```
4. Verify the tag exists:
   ```bash
   git tag
   ```
   *(Output should show `v1.0.0`)*
5. Inspect the specific details of the annotated tag:
   ```bash
   git show v1.0.0
   ```
   *(Notice it prints the Tagger name, the date, your custom message, AND the commit code it points to).*
6. **The Critical Step (Pushing):** Standard `git push` commands do NOT push tags to GitHub. You must push tags explicitly.
   ```bash
   # Push a specific tag
   git push origin v1.0.0
   
   # Or push all tags you have created locally
   git push origin --tags
   ```

### 7. Release Automation via Tags
In modern DevOps (like GitHub Actions or GitLab CI), Tags are magic triggers.
You can configure your `.gitlab-ci.yml` pipeline with a rule:

yaml deploytoproduction: script: ./deploy.sh only:

• tags

• Never Move a Tag: Once an Annotated Tag is pushed to a public repository and deployed, it is mathematically sacred. If you discover a bug 5 minutes later, DO NOT delete the v1.0.0 tag, fix the bug, and recreate v1.0.0. This breaks the fundamental law of version control. Fix the bug, commit it, and create v1.0.1.

• Checking out a Tag (Detached HEAD): If you type git checkout v1.0.0 to look at old code, Git warns you that you are in a "Detached HEAD" state. Because a tag is frozen and cannot be modified, any commits you make while standing on a tag will be lost. If you want to fix an old version, you must branch off the tag: git checkout -b hotfix-v1.0 v1.0.0.

1. 2. According to Semantic Versioning (SemVer), what specific type of code change justifies incrementing the MAJOR version number (e.g., from v1.2 to v2.0)?

12. Summary #

13. Next Chapter Recommendation #