Scaled Trunk-Based Development

with Rebase Workflow

Date: 2024-05-20 • Status: Accepted

Context: Development Team, DevOps

1. The Problem

Our current "GitFlow" strategy is causing:

Code Loss: Valid changes overwritten during complex merges.
Integration Hell: Spending days resolving conflicts, not coding.
Branch Sprawl: A "spaghetti" git graph that is impossible to read.

2. The Decision

We are adopting a Rebase-then-Merge policy.

✅ Primary Branch: main (Single source of truth)

✅ Feature Branches: Short-lived (2-3 days max)

✅ Conflicts: Resolved daily via rebase

✅ Merging: --no-ff to keep history bubbles

3. Workflow: Start Ticket

Features must start from the latest stable code.


# 1. Update local main
git checkout main
git pull origin main

# 2. Create feature branch
git checkout -b JNET-123-ticket-branch

3. Workflow: Sync (Daily)

Prevent "Branch Hell" by syncing daily.


git fetch origin main

# Replay your work on top of latest main
git rebase origin/main

# Update remote (Lease protects overwrites)
git push origin --force-with-lease

3. Workflow: PR & Merge

The merge creates a visual "bubble" in the history.


# Create PR via CLI
gh pr create --base main \
             --head JNET-123-ticket-branch \
             --title "🚀 Release $(date +%F)"

# Merge preserving history bubble
gh pr merge --merge

4. Release Strategy

We decouple Merge from Release.

Phase A: Auto-Staging

Merge to Main → Auto-Deploy to Staging

Phase B: "Create Release"

Trigger "Create Release" Workflow
System tags commit (v1.2.0)
Deploys to Prod Preview
Promotes to Prod Live

5. Hotfix Strategy

Do not wait for the next full release.


# 1. Target the release branch
git checkout release/v1.2.0

# 2. Apply fix & push (Triggers Prod Deploy)
git commit -m "FIX: Critical bug JNET-999"
git push origin release/v1.2.0

Critical: Back-Port to Main

Ensure the fix doesn't disappear in v1.3.0.


git checkout main

# Cherry-pick the fix hash
git cherry-pick 

git push origin main