Day 8 - Git Branching Strategy — Real-World Explanation

🧠 1. Why Branching Strategy is Important

In any software organization, the main goal is to ensure that customers get new features and bug fixes quickly and reliably.

• Frequent releases keep users engaged and happy.

• Companies like Amazon or Flipkart release updates every 15 days, monthly, or quarterly.

• To manage these frequent updates efficiently, a proper branching strategy in Git is essential.

Without a good strategy:

• Code merges can become messy.

• Teams can overwrite each other’s work.

• Releases can break production.

✅ A branching strategy helps teams develop, test, and release features smoothly and safely.

---

🌳 2. What is a Branch in Git?

A branch is a separate line of development created from the main codebase.
It allows developers to work on new features or fixes without disturbing the main code.

---

🧩 Example — Calculator App

Let’s say you have a Calculator App with basic features:

• Addition

• Subtraction

• Multiplication

• Division

Now you want to add version 2 (V2) with new features like:

• Percentage

• Advanced calculations

Instead of changing the main branch (main/master) directly, you create a new branch called:

feature/v2

You:

1. Develop and test all new code in this branch.

2. Merge it into the main branch once it’s stable.

3. Delete the feature branch after merging.

✅ This ensures the main branch stays stable until changes are fully tested.

---

🛵 Real Example — Uber

Initially, Uber only supported Cabs.
Later, they wanted to add Bikes as a new service.

Steps:

1. Developers created a new branch called feature/bikes.

2. They developed and tested the new “bike” code independently.

3. Once confident it works, they merged it back into the main branch.

4. The “feature/bikes” branch was deleted after merging.

🧩 Reason: The main “Cab” app kept running without being affected by incomplete “Bike” code.

---

⚙️ 3. Types of Branches in a Good Strategy

A good Git branching strategy generally involves four key branch types:

Let’s break each one down 👇

---

🧱 3.1 Main (or Master) Branch

• The default branch in any repository.

• Contains the latest stable code.

• All tested and approved changes are merged here.

• Active development happens through feature branches, not directly on master.

---

🌟 3.2 Feature Branch

• Created for new features or major changes.

• Keeps risky changes isolated from stable code.

• Once feature is tested → merged into main branch.

Example:

feature/percentage
feature/exponential
feature/division

✅ Developers work independently on each feature.
✅ After validation, all are merged into main.

---

🚀 3.3 Release Branch

• Created when a product is ready for deployment.

• Example:

    release/v1.0
    release/v2.0
  

• Purpose:

  • Final testing before going live.

  • Avoids last-minute changes entering the release.

  • Ensures stability while active development continues in main.

Why not release directly from main?

• Because main often has ongoing development.

• Release branches allow controlled testing and deployment.

✅ Once tested → build & ship from release branch.
✅ Post-release, merge it back into main.

---

🔥 3.4 Hotfix Branch

• Used for critical production bugs.

• Short-lived (1–2 days).

• Example:

    hotfix/login-issue
  

Steps:

1. Create from the latest release branch.

2. Fix the bug, test it.

3. Merge it into both:

   • main (so the latest code stays updated)

   • release (so the fix goes live)

✅ Ensures both development and production have the fix.

---

🧩 4. Real-World Example — Kubernetes Project

Kubernetes (open-source, hosted on GitHub) follows a similar branching strategy.

• Over 3,300 contributors collaborate on the codebase.

• They maintain:

  • A main/master branch for active development.

  • Multiple feature branches like:

    • feature/rate-limiting

    • feature/server-set

    • feature/workload-GA

  • Release branches for versions:

    • release-1.26

    • release-1.27

📦 Kubernetes Release Flow:

1. Developers work on feature branches.

2. Merge changes into master after review.

3. Create a release branch for the next version (e.g., release-1.27).

4. Test and stabilize this branch.

5. Ship this code to users.

✅ After the release, all new features continue on master.
✅ The release branch code represents what customers use.

---

🧭 5. Visual Summary

                +---------------------+
                |      MAIN/MASTER    | ← Always stable, latest code
                +---------------------+
                   ↑           ↑
          (merge) /             \ (merge)
       +-----------+         +------------+
       | Feature 1 |         | Feature 2  | ← Feature branches for new work
       +-----------+         +------------+
             ↓
             ↓  (Once stable)
             ↓
      +--------------------+
      |   Release Branch   | ← Used for testing & shipping builds
      +--------------------+
             ↓
             ↓ (Deployed)
             ↓
      +--------------------+
      |   Production Code  |
      +--------------------+
             ↑
             ↑
      +--------------------+
      |   Hotfix Branch    | ← Urgent production fixes
      +--------------------+

---

🧩 6. How It Works in an Example Project (Uber)

✅ The cycle repeats for every version.

---

🧩 7. Interview-Focused Summary

---

✅ 8. Best Practices

1. Keep main branch always clean and stable.

2. Always create feature branches for new changes.

3. Merge changes only through pull requests (PRs).

4. Create release branches for testing before deployment.

5. Merge hotfixes into both release and main branches.

6. Delete stale branches once merged.

---

🏁 9. Summary

✅ All changes eventually merge back into main so it stays the latest and most complete version.

---

In Short:

• Developers build features in feature branches.

• Test and deploy from release branches.

• Fix urgent bugs via hotfix branches.

• Keep master branch always clean and updated.