Prefer branching from main (or master), not from another feature branch — unless explicitly required

---

🚦 The Rule

“Always create a new branch from main (or master), not from another feature branch.”

---

❓ Why This Rule Exists

1. Avoid Carrying Unrelated Changes

   • If you branch off from another feature branch, your new branch will contain:

     • Your changes + all the unfinished/unmerged work from that feature branch.

   • This makes your branch “dirty” with unrelated commits.

🔴 Example:

    main → feature-A
                ↳ feature-B (created from feature-A)

Now feature-B includes all of feature-A’s code, even if feature-A is not merged yet.
If feature-B gets merged first, it might pull in feature-A’s half-done work.

---

2. Cleaner Pull Requests (PRs)

   • When you make a PR from feature-B, reviewers see changes from both feature-A + feature-B.

   • This makes code review confusing, as reviewers can’t easily tell what belongs to your task.

---

3. Avoid Merge Conflicts Later

   • If feature-A changes a lot before merging, then feature-B (branched off from it) will constantly face merge conflicts.

   • If you branched from main, you only deal with conflicts once when merging your own work.

---

4. Independent Features

   • Features should be independent. If feature-B actually depends on feature-A, that’s a special case — but normally, features should stand alone and merge cleanly into main.

---

5. Predictable Git History

   • Branching from main keeps history simple:

     • main → feature-A

     • main → feature-B

   • No accidental “chaining” where branches depend on each other unnecessarily.

---

✅ Correct Workflow Example

main
 ├── feature-A
 └── feature-B

Both start from main.
Each PR only shows its own changes.
They can be merged in any order.

---

⚠️ Wrong Workflow Example

main
 └── feature-A
        └── feature-B

• feature-B contains code from both A + B.

• If feature-A is delayed, feature-B is blocked.

• Code reviews and merges become messy.

---

🧑‍💻 Real-Life Example

Imagine you’re building an app:

• feature-A = Add Login Page

• feature-B = Add Dashboard

If you make feature-B from feature-A, then your dashboard branch also has the login page (even if not ready).
If the team merges feature-B first, the login code sneaks in too, even though it’s incomplete. That’s risky.

---

📌 Exceptions (When You Might Branch Off Another Feature)

• When one feature truly depends on another (e.g., feature-B requires feature-A to exist).

• In that case, you branch from feature-A, but you should note in your PR:

  “This branch depends on feature-A — merge feature-A first.”

---

👉 In short:
Branch from main to keep branches clean, independent, and reviewable. Only branch from another feature if it’s a hard dependency.

---