Git Branching Strategy

Prevent monster branches by following disciplined branching and merge practices.

When to Use This Skill

Invoke this skill when:

✅ Starting New Work

• About to implement a new feature
• Planning to fix a bug
• Starting refactoring work
• Adding documentation

⚠️ Mid-Feature Warning Signs

• Thinking "while I'm here, I'll also..."
• Wanting to add unrelated functionality
• Branch has grown beyond 20 commits
• Multiple unrelated files changed
• Changes would be difficult to understand

🎯 Decision Points

• Unsure whether to create new branch or continue current
• Wondering if branch is getting too large
• Considering adding "just one more thing"
• Ready to merge but branch feels messy

---

⚠️ Pre-Implementation Checklist

BEFORE writing ANY code, answer these questions:

1. Is this non-trivial work?

Non-trivial = ANY of these:

• ✅ Changes >2 files
• ✅ Refactoring existing code
• ✅ Adding new features/functionality
• ✅ Implementing planned tasks
• ✅ Bug fixes requiring changes to multiple components

Trivial = ALL of these:

• ❌ Fixing typo in single file
• ❌ Updating documentation only (markdown, comments)
• ❌ One-line fix in single file

2. If Non-Trivial → CREATE FEATURE BRANCH

# Ensure main branch is up to date
git checkout main
git pull origin main

# Create feature branch (choose appropriate prefix)
git checkout -b feature/descriptive-name    # For new features
git checkout -b refactor/descriptive-name   # For refactoring
git checkout -b fix/descriptive-name        # For bug fixes

Examples:

• feature/user-authentication

  - New auth implementation

• refactor/error-handling

  - Standardize error handling

• fix/login-redirect

  - Fix login redirect bug

3. Golden Rule

When in doubt, use a feature branch.

Feature branches provide:

• 📝 Documentation of what changed and why
• 📊 Clear history of feature development
• 🔄 Easy to revert if needed
• 🧪 Isolated testing before merge

---

The Problem: Monster Branches

What Happens

Timeline:

• Started as "add feature X"
• Grew to include features Y, Z, refactoring, and bug fixes
• 100+ commits, multiple intertwined features
• Difficult to review, hard to merge, risky to revert

Symptoms:

• ❌ Multiple distinct features mixed together
• ❌ Hard to describe what the branch does in one sentence
• ❌ Changes span unrelated systems
• ❌ Commit history is difficult to follow
• ❌ Rolling back one feature means losing others

Consequences:

• Long-lived branch diverges from main
• Merge conflicts accumulate
• Testing becomes all-or-nothing
• Can't ship features incrementally
• Hard to isolate bugs introduced

Solution: Small, Focused Branches

The Golden Rule

One feature, one branch, one merge.

If you can't describe the branch in a single sentence without using "and", it's too big.

Good Examples

✅ Good:

feat/user-auth

- "Add basic user authentication" ✅ Good:

feat/smart-fields

- "Implement smart field system" ✅ Good:

fix/race-condition

- "Fix optimistic update race condition" ✅ Good:

refactor/scss-modules

- "Convert SCSS to module system" ✅ Good:

docs/contributing

- "Add contributing guidelines"

Bad Examples

❌ Bad:

feat/improvements

- Too vague, likely includes unrelated changes ❌ Bad:

fix/various-bugs

- Multiple unrelated fixes should be separate branches ❌ Bad:

wip/stuff

- Not descriptive, suggests unfocused work

Branch Size Guidelines

Target Size

Ideal: 5-15 commits, 1-5 files changed significantly Acceptable: Up to 30 commits, up to 10 files Too Large: 50+ commits, 20+ files

Exception: Large refactors that are purely mechanical

Commit Count Checkpoints

5 commits → Normal feature pace
10 commits → Check: Am I still focused on one feature?
20 commits → WARNING: Consider splitting or wrapping up
30 commits → CRITICAL: Finish and merge, or split into multiple branches
50+ commits → MONSTER: This should have been 3-5 separate branches

When Branch Size is Justified

✅ Acceptable large branches:

• Pure refactoring (converting styles, modularization)
• Data migrations (changing structure across many files)
• Framework version upgrades (mechanical API changes)
• Initial feature implementation with tests and docs

❌ Unacceptable large branches:

• Multiple unrelated features
• Feature + "while I'm here" improvements
• Feature + unrelated bug fixes
• Feature + refactoring that isn't required for feature

Decision Tree: New Branch or Continue?

Question 1: Is this change related to current branch?

New change → Related to current feature?
  ↓ YES (same system, same goal)
  → Continue current branch

  ↓ NO (different system, different goal)
  → Question 2

Question 2: Is current branch ready to merge?

Current branch → Ready to merge?
  ↓ YES (feature complete, tests pass)
  → Merge current, then new branch for new work

  ↓ NO (feature incomplete)
  → Question 3

Question 3: Is new work required for current feature?

New work → Required for current feature to work?
  ↓ YES (dependency)
  → Continue current branch

  ↓ NO (nice-to-have, improvement, unrelated)
  → Stash current, new branch, finish new, resume current

Branch Naming Conventions

Format

<type>/<short-description>

Types

• feat/ - New feature or enhancement
• fix/ - Bug fix
• refactor/ - Code restructuring without behavior change
• docs/ - Documentation only
• test/ - Adding or fixing tests
• chore/ - Build, tooling, dependencies

Examples

feat/user-auth
feat/smart-fields
feat/dashboard
fix/login-redirect
fix/memory-leak
refactor/scss-modules
refactor/modularization
docs/contributing
docs/api-guide
chore/update-deps

Avoid

❌

feature/

- Use

feat/

(shorter) ❌

bugfix/

- Use

fix/

(shorter) ❌

wip/

- Work in progress is implied, use descriptive name ❌

my-branch

- Not descriptive ❌

feat/add-feature

- Redundant "add"

Branch Lifecycle

1. Plan and Scope

Before creating branch:

• Can I describe this in one sentence?
• Is this the smallest useful increment?
• Does this depend on other incomplete work?
• Will this take more than 30 commits?

If >30 commits expected: Break into smaller features first.

2. Create Branch

# From main (or integration branch)
git checkout main
git pull origin main

# Create feature branch
git checkout -b feat/descriptive-name

3. Work on Feature

Commit discipline:

• Small, focused commits
• Clear commit messages
• Commit related changes together
• Don't mix formatting with logic changes

Check progress regularly:

# How many commits?
git log main..HEAD --oneline | wc -l

# How many files changed?
git diff main --stat

# Am I still focused?
git log --oneline -10  # Review recent commits

4. Recognize When to Split

Warning signs:

• Commit messages use "and" frequently
• Multiple unrelated

  // TODO

  comments
• You've forgotten what early commits did
• Summary of changes needs 3+ bullet points for unrelated changes

How to split:

# Option A: Finish current, branch for next
git commit -m "Complete X feature"
# Merge feat/x
git checkout -b feat/y  # Start next feature

# Option B: Stash incomplete, branch for urgent work
git stash
git checkout -b fix/urgent-bug
# Fix and merge
git checkout feat/original
git stash pop

5. Prepare for Merge

Before merging:

# Rebase on latest main
git fetch origin
git rebase origin/main

# Review all changes
git diff origin/main

# Check commit history is clean
git log origin/main..HEAD --oneline

# Run tests if applicable
npm test  # or your test command

6. Merge to Main

# Switch to main and merge
git checkout main
git pull origin main
git merge --no-ff feat/descriptive-name

# Push to remote
git push origin main

# Delete local branch
git branch -d feat/descriptive-name

Note:

--no-ff

creates a merge commit even for fast-forward merges, preserving branch history.

Commit Message Conventions

Format

<type>: <short description>

<optional body>

<optional footer>

Types

Same as branch types:

• feat: - New feature
• fix: - Bug fix
• refactor: - Code restructuring
• docs: - Documentation
• test: - Tests
• chore: - Build/tooling

Guidelines

Good commit messages:

feat: Add smart field system with lookups

Implements interactive fields that open selection dialogs
filtered by context. Includes helper and click handler integration.

Closes #42

Bad commit messages:

❌ "Updates"
❌ "Fix stuff"
❌ "WIP"
❌ "More changes"
❌ "Final commit (hopefully)"

Commit Message Best Practices

• Present tense: "Add feature" not "Added feature"
• Imperative mood: "Fix bug" not "Fixes bug"
• Capitalize first word: "Add feature" not "add feature"
• No period at end: "Add feature" not "Add feature."
• Body explains why, not what: Code shows what, message explains why

When to Split an Existing Branch

Recognize the Need

You should split if:

• Branch has 40+ commits and isn't done
• You can't summarize the changes coherently
• Rolling back would lose multiple independent features
• Commit history mixes unrelated changes

How to Split

Strategy A: Extract Completed Features

# Current branch: feat/massive (50 commits)
# Goal: Extract first feature into separate branch

# 1. Create new branch from main
git checkout main
git checkout -b feat/extracted-feature

# 2. Cherry-pick relevant commits
git log feat/massive --oneline  # Find commit SHAs
git cherry-pick abc123 def456 ghi789

# 3. Merge the extracted feature
git checkout main
git merge --no-ff feat/extracted-feature
git push origin main
git branch -d feat/extracted-feature

# 4. Rebase massive branch to remove duplicates
git checkout feat/massive
git rebase main

Strategy B: Start Fresh, Reference Old

# Current branch: feat/massive (too messy to salvage)

# 1. Create new branch from main
git checkout main
git checkout -b feat/feature-1-clean

# 2. Manually apply changes from massive branch
# (Copy files, make clean commits)

# 3. Repeat for each feature
git checkout main
git checkout -b feat/feature-2-clean

# 4. Abandon feat/massive after all features extracted
git branch -D feat/massive

Quick Checklist

Before Starting Work

• One sentence description of what I'm building
• Checked if this should be separate from current branch
• Created appropriately named branch from main
• Estimated this will take <30 commits

During Work

• Commit messages are clear and focused
• Not mixing unrelated changes in same commit
• Checking commit count every 5-10 commits
• Resisting "while I'm here" temptations

Before Merging

• Branch has <30 commits (or justifiable if larger)
• All commits are related to the same feature
• Rebased on latest main
• Can describe changes in 1-3 sentences
• Commit history is clean and logical
• Tests pass (if applicable)

Danger Signs (Stop and Split)

• ⚠️ More than 30 commits
• ⚠️ Changed more than 15 unrelated files
• ⚠️ Commit messages have "also", "and", "while here"
• ⚠️ Can't remember what early commits did
• ⚠️ Summary needs multiple unrelated bullet points

Common Scenarios

"I'm halfway through feature X, noticed bug Y"

If bug blocks feature X: → Fix in current branch

If bug is unrelated: → Stash current work, create

fix/bug-y

, merge it, resume feature X

"I want to add feature B while working on feature A"

If B is required for A: → Continue current branch

If B is independent: → Finish A first, then branch for B

If B is urgent and A is incomplete: → Stash A, branch for B, merge B, resume A

"My branch has 40 commits, should I split?"

Yes. Options:

1. Extract completed portions into separate branches (cherry-pick)
2. Finish current branch as-is, vow to split next time
3. Start fresh with clean branches for each feature

"I made formatting changes along with feature changes"

Separate them:

# Approach 1: Amend last commit to remove formatting
git reset HEAD~1
git add <feature files only>
git commit -m "feat: add feature"
git add <formatting files>
git commit -m "chore: format code"

# Approach 2: Split into two branches
# - Branch 1: Formatting only (refactor/format-cleanup) - merge first
# - Branch 2: Feature only (feat/my-feature) - merge after

---

Remember: When in doubt, split it out. Smaller branches are easier to understand, safer to merge, and faster to ship.

---

Last Updated: 2026-01-05