Branching Strategies — Animate | AI Wisdom

← Back to topic
🎞 ANIMATE · Mode 3 of 5 · +100 XP— Git Branching Strategies
📋Trunk
⚙️Feature Flags
🔄Commits
✅Release
🎯 Next: Test →
Step 1 / 4
Speed
Trunk-Based Dev
One "main" branch always deployable — feature branches live < 2 days💡 Analogy
Like a newspaper — everyone contributes to tomorrow's edition daily, not separate papers merged at the last minute.
Trunk-based development: one main branch, short-lived feature branches merged daily. Avoids long-running branches with massive merge conflicts.
Console Output
> main: always deployable ✅
> feature/add-search: 18h old → PR → merge
> feature/fix-bug: 4h old → PR → merge
> NO long-lived develop/release branches
●branching.yml
Trunk-Based DevL1–11
1# Trunk-Based Development with feature flags
2# Main branch is always deployable
3 
4name: TBD Workflow
5on:
6  push:
7    branches: [main]          # only one long-lived branch
8  pull_request:
9    branches: [main]
10 
11# Feature branches: short-lived (< 2 days)
12# feature/add-search → main (via PR, CI must pass)
13 
14# Feature flags enable incomplete features in production
15# config/features.json:
16# {
17#   "new-search": { "enabled": false, "rollout": 0.0 },
18#   "ai-chat":    { "enabled": true,  "rollout": 0.1 }  // 10% of users
19# }
20 
21# Conventional Commits: parsed by semantic-release
22# feat: add vector search          → MINOR version bump (1.x.0)
23# fix: correct pagination offset   → PATCH version bump (1.0.x)
24# feat!: redesign API endpoints    → MAJOR version bump (x.0.0)
25 
26# Release process: automatic via semantic-release
27# 1. Commit pushed to main
28# 2. semantic-release reads commit messages
29# 3. Determines version bump (patch/minor/major)
30# 4. Creates git tag + CHANGELOG.md + GitHub Release
31# 5. CI deploys tagged version to production
32 
33# NEVER force-push main
34# ALWAYS use squash-merge for clean history
35# PR approval + CI required before merge
35 lines
Timeline — 4 Steps
Trunk-Based Dev
One "main" branch always deployable — feature branches live < 2 days💡 Analogy
Like a newspaper — everyone contributes to tomorrow's edition daily, not separate papers merged at the last minute.
Trunk-based development: one main branch, short-lived feature branches merged daily. Avoids long-running branches with massive merge conflicts.
Console Output
> main: always deployable ✅
> feature/add-search: 18h old → PR → merge
> feature/fix-bug: 4h old → PR → merge
> NO long-lived develop/release branches

Was this page helpful?

Discussion

One "main" branch always deployable — feature branches live < 2 days

💡 Analogy

Like a newspaper — everyone contributes to tomorrow's edition daily, not separate papers merged at the last minute.

Trunk-based development: one main branch, short-lived feature branches merged daily. Avoids long-running branches with massive merge conflicts.

Console Output

> main: always deployable ✅
> feature/add-search: 18h old → PR → merge
> feature/fix-bug: 4h old → PR → merge
> NO long-lived develop/release branches

One "main" branch always deployable — feature branches live < 2 days

💡 Analogy

Like a newspaper — everyone contributes to tomorrow's edition daily, not separate papers merged at the last minute.

Trunk-based development: one main branch, short-lived feature branches merged daily. Avoids long-running branches with massive merge conflicts.

Console Output

> main: always deployable ✅
> feature/add-search: 18h old → PR → merge
> feature/fix-bug: 4h old → PR → merge
> NO long-lived develop/release branches