π― Use Case: You want to support two different versions of your web app β one for existing users (v1), and another for upcoming features (v2).
Release branching helps you develop and maintain both versions at the same time β safely and cleanly.
π§ Project: myshop-demo (Online Store)
π Scenario:
- Version 1 (release/v1) is live, stable, and used by customers.
- Version 2 (release/v2) is under development with a new UI.
Your task:
- Add a new UI message in v2
- Apply a hotfix in v1
- Without affecting each other
π§ͺ Letβs Do It β Step-by-Step in Git
β
Step 1: Initialize the Project (if not already)
mkdir myshop-demo
cd myshop-demo
git init
echo "<h1>Welcome to MyShop</h1>" > index.html
git add .
git commit -m "Initial MyShop homepage"
β
Step 2: Create Two Release Branches
# Simulate production branch for v1
git checkout -b release/v1
# Push if needed
git push origin release/v1 # Optional
# Create v2 from v1
git checkout -b release/v2
β
Step 3: Add New Feature in v2
echo "<p>π New UI coming soon in v2!</p>" >> index.html
git commit -am "Add teaser for new UI in v2"
β Youβve added a new feature in v2, safely isolated from v1.
β
Step 4: Switch to v1 and Apply Hotfix
git checkout release/v1
echo "<!-- Fixed product price rounding issue -->" >> index.html
git commit -am "Hotfix: correct price rounding logic"
β Youβve fixed a bug in v1 without affecting v2's progress.
π What Just Happened?
Branch | Change Description |
---|---|
release/v1 |
Hotfix added safely to the live version |
release/v2 |
Continued development of new features |
π§ Real-World Example
Imagine you're a SaaS company:
- Team A patches a bug on release/v1 for current customers.
- Team B develops a new UI in release/v2.
π§ Both teams work in parallel β no conflicts, no waiting.
π Why Use Release Branching?
β Pros | β Cons |
---|---|
Support multiple versions easily | Can get branch-heavy over time |
Isolate hotfixes from new features | Requires discipline and versioning |
Ideal for enterprise + versioned apps | Not great for rapid CD-only teams |
π§Ό Bonus Tip: Merge v1 Hotfix into v2
You may want to apply the same hotfix to v2:
git checkout release/v2
git merge release/v1
β Now release/v2 includes the v1 fix too.
π§ͺ Summary
- release/v1 = Stable production branch with hotfixes
- release/v2 = New feature development
- You managed both versions without interfering
β Youβre Now One Step Closer to Git Mastery!
Drop a β€οΈ or π¦ if this helped you.
π Comment below β Iβd love to help you practice!
Please have a look Trunk Based Development Branching Strategy
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.