DEV Community

Riazul Karim Ivan
Riazul Karim Ivan

Posted on

Managing Multi-Branch Development with Inter-Dependent Features (Without Merge Hell)

#leadership #git #product

Real-world strategy for complex Android / backend teams building dependent features with staggered releases.

🎯 Problem Scenario

You have:

  • Multiple teams working in parallel
  • Feature dependencies (Feature 2 depends on Feature 1)
  • Partial releases
  • Feature flags controlling exposure
  • Independent features going on at the same time

Release Plan

Week Release Content
Week 1 Feature 1 (Partial)
Week 2 Feature 1 (Controlled) + Feature 2 (Partial)
Final Feature 1 (Full)
Final Feature 2 (Full)

And some parts of Feature 1 must be OFF while Feature 2 is released.

This is not theoretical. This is production reality.

🚨 What Goes Wrong Without Strategy

  • Massive merge conflicts
  • Long-lived feature branches
  • Inconsistent environments
  • Broken CI
  • “It works in my branch” syndrome
  • Release panic

So we need:

✔ Predictable branch flow
✔ Clear dependency control
✔ Controlled releases
✔ Feature isolation
✔ Conflict minimization

🏗 Branching Strategy Overview

Instead of long-lived feature branches merging at the end, we use:

  • main → Production
  • develop → Integration
  • release/* → Weekly release branches
  • feature/* → Short-lived branches
  • Feature Flags → Control exposure

🌳 High-Level Branch Flow 

main
  |
  |-----------------------------|
  |                             |
develop -------------------------
  |         |          |      |
  |         |          |      |
feature/F1  feature/F2 feature/F3 (independent)
   |            |
   |            |
   |------------|
        (merge early because F2 depends on F1)
Enter fullscreen mode Exit fullscreen mode

🔥 Core Principle #1 — Merge Early, Hide with Feature Flags

Instead of waiting:

❌ Don’t keep Feature 1 in isolation until fully complete.

Instead:

✅ Merge incomplete Feature 1 to develop
✅ Hide incomplete parts behind feature flags

Example:

if (featureToggle.isFeature1PartialEnabled()) {
   showNewDashboard()
}
Enter fullscreen mode Exit fullscreen mode

Feature toggles let you:

  • Merge early
  • Reduce conflicts
  • Control rollout
  • Disable partial implementation

This is critical in fintech apps.

🧩 Handling Feature Dependency (F2 depends on F1)

Correct Approach

  1. F1 starts from develop
  2. F1 merges to develop early (behind flag)
  3. F2 branches from updated develop
  4. F2 builds on F1’s base safely

Why?

If F2 branches before F1 merges →
You create a dependency merge nightmare later.

📅 Week-by-Week Flow
🟢 Week 1 → Release Partial Feature 1
Branch Structure

develop
   |
   |---- release/week-1
Enter fullscreen mode Exit fullscreen mode

Steps:

  1. Merge partial F1 into develop
  2. Create release/week-1
  3. Enable only partial F1 via feature flag
  4. Merge release into main
  5. Tag version 
main ← release/week-1
Enter fullscreen mode Exit fullscreen mode

🟡 Week 2 → Release F2 + Controlled F1

Now:

F2 already built on F1 (because F1 was merged early)

Some F1 parts must remain OFF

Branch Flow

develop
   |
   |---- release/week-2
Enter fullscreen mode Exit fullscreen mode

Enable:

  • F2 partial → ON
  • F1 advanced parts → OFF

Controlled via:

  • Remote config
  • Build config
  • Runtime toggles

No branching trick. Just feature control.

🏁 Final Releases

When Feature 1 is complete:

  • Ensure all parts merged into develop
  • Enable all F1 flags
  • Create release branch
  • Merge to main
  • Same for Feature 2.

🔁 Independent Feature Development

Now let’s add complexity:

Feature 3, Feature 4, Feature 5
All independent.

Branch Structure

develop
 |  |  |  |
F1 F2 F3 F4
Enter fullscreen mode Exit fullscreen mode

Rules:

✔ All feature branches short-lived
✔ Rebase frequently from develop
✔ Merge early
✔ Use feature flags
✔ Avoid feature-to-feature direct merges

⚔ Conflict Minimization Rules

Rule 1 — No Long-Lived Feature Branches

If a branch lives > 1 week → risk increases 3x.

Merge incomplete but hidden.

Rule 2 — Daily Rebase or Merge from Develop 

git checkout feature/F2
git fetch
git rebase origin/develop
Enter fullscreen mode Exit fullscreen mode

This keeps branch fresh.

Rule 3 — Avoid Branching from Another Feature

Never:

feature/F2 from feature/F1
Enter fullscreen mode Exit fullscreen mode

Always:

feature/F2 from develop
Enter fullscreen mode Exit fullscreen mode

Even if dependent.

Because F1 should already be merged (hidden).

Rule 4 — One Release Branch Per Release

Release branches are temporary stabilization zones.

develop → release/x → main
Enter fullscreen mode Exit fullscreen mode

Hotfix goes:

main → hotfix/x → main → develop
Enter fullscreen mode Exit fullscreen mode

📊 Full Flow Diagram (Complex Case) 

                      main
                        ^
                        |
                release/week-1
                        ^
                        |
develop ----------------|----------------------
 |      |        |      |        |          |
F1      F2       F3     F4       F5         F6
 |       |
 |-------|
 (F2 depends on F1)
Enter fullscreen mode Exit fullscreen mode

🧠 Advanced Technique (For Large Teams)

If you are working in something like:

  • Multi-module Android Super App
  • Microservice backend
  • Fintech compliance system

Then consider:

1️⃣ Module Isolation

Feature per module reduces conflict dramatically.

2️⃣ Trunk-Based Development (Advanced)

For very mature teams:

  • No long feature branches
  • Everyone merges to develop daily
  • Everything hidden behind flags

Used by:

  • Google
  • Meta
  • Netflix

🎛 Feature Flag Strategy (Very Important)

Types of flags:

Type Purpose
Build-time Separate flavor builds
Runtime Enable/disable dynamically
Remote config Gradual rollout

Example in fintech:

  • Enable new KYC flow only for 10% users
  • Enable F2 only after F1 baseline stable

💥 What This Achieves

✔ Minimal conflicts
✔ Parallel development
✔ Safe dependency handling
✔ Flexible release planning
✔ Faster CI stability
✔ Reduced stress before release

🏆 Final Golden Rules

  1. Merge early.
  2. Hide incomplete work with flags.
  3. Never branch from another feature.
  4. Rebase frequently.
  5. Keep release branches short-lived.
  6. Prefer integration over isolation.

🔚 Final Thought

Multi-feature development is not about Git tricks. It’s about discipline and integration mindset.

The real mistake teams make is confusing branch isolation with feature isolation.

Isolation should happen via flags — not branches.

Top comments (0)