Branching Best Practices

The Hook (The "Byte-Sized" Intro)

The difference between a repo you enjoy working in and one that makes you want to quit isn't the framework or the language — it's how the team uses branches. Short-lived branches, clear names, frequent merges, no dead branches — these aren't opinions, they're battle-tested habits from teams shipping software at Google, Shopify, and Stripe. Here are the rules they follow.

📖 What are Branching Best Practices?

These are practical habits that keep branch workflows clean, fast, and conflict-free. They apply whether you're working solo or in a team of 50.

Conceptual Clarity

The 7 rules of great branching:

#	Rule	Why
1	Keep branches short-lived	Long branches diverge → big conflicts
2	Use clear naming conventions	`feature/login` > `my-branch`
3	Branch from the latest `main`	Starting from stale code means more conflicts
4	Merge often	Small merges are easy; big merges are painful
5	Delete merged branches	Clean branch lists reduce confusion
6	One branch = one purpose	Don't mix unrelated changes
7	Never commit directly to `main`	Use PRs for code review and CI

Real-Life Analogy

Branching best practices are like kitchen rules:

Clean as you cook (delete merged branches)
Don't mix raw and cooked ingredients (one branch = one feature)
Keep your workspace organized (naming conventions)
Taste frequently (merge often, test early)

Visual Architecture

gitGraph commit id: "v1.0" branch feature/auth checkout feature/auth commit id: "Add auth" commit id: "Add tests" checkout main merge feature/auth id: "PR #42" branch bugfix/nav checkout bugfix/nav commit id: "Fix nav" checkout main merge bugfix/nav id: "PR #43" commit id: "v1.1"

Why It Matters

Fewer conflicts: Short branches + frequent merges = smaller diffs = fewer conflicts.
Better reviews: Small, focused PRs are reviewed faster and more thoroughly.
Faster shipping: Teams that merge daily ship features weekly. Teams that merge monthly... don't.
Onboarding: New team members understand a clean repo in minutes instead of hours.

Code

bash

# ─── Always start from latest main ───
git switch main
git pull origin main
git switch -c feature/user-profile

# ─── Keep your branch up-to-date while working ───
# Option 1: Merge main into your branch
git switch feature/user-profile
git merge main

# Option 2: Rebase onto main (cleaner history)
git switch feature/user-profile
git rebase main

# ─── Before opening a PR: clean up ───
git switch main
git pull origin main
git switch feature/user-profile
git rebase main                    # Resolve any conflicts
git push origin feature/user-profile

# ─── After PR is merged: clean up ───
git switch main
git pull origin main
git branch -d feature/user-profile
git push origin --delete feature/user-profile

# ─── Find stale branches to clean up ───
git branch --merged main
# Output: lists branches that are fully merged and safe to delete

git for-each-ref --sort=-committerdate --format='%(committerdate:short) %(refname:short)' refs/heads/
# Output: all branches sorted by last commit date — oldest = stale

Branch Naming Conventions

Prefix	Purpose	Example
`feature/`	New functionality	`feature/JIRA-456-user-profile`
`bugfix/`	Non-urgent bug fixes	`bugfix/JIRA-789-login-redirect`
`hotfix/`	Urgent production fixes	`hotfix/security-patch-v2.1`
`release/`	Release preparation	`release/v2.1.0`
`chore/`	Maintenance (deps, CI)	`chore/upgrade-node-18`
`docs/`	Documentation changes	`docs/api-reference-update`
`test/`	Test additions/changes	`test/add-e2e-coverage`

Branch Lifespan Guidelines

Branch Type	Ideal Lifespan	Max Before Alarm
`feature/`	1-3 days	1 week
`bugfix/`	Hours to 1 day	3 days
`hotfix/`	Minutes to hours	1 day
`release/`	1-3 days	1 week
`chore/`	Hours to 1 day	3 days

Key Takeaways

Keep branches short-lived — merge within days, not weeks.
Use clear naming conventions with prefixes like feature/, bugfix/, hotfix/.
Always branch from the latest main and keep your branch updated.
Delete merged branches immediately — both local and remote.
One branch = one purpose. Never mix unrelated changes.

Interview Prep

Q: Why should branches be short-lived? A: Long-lived branches diverge significantly from main, leading to large, complex merge conflicts. Short-lived branches stay close to main, resulting in smaller diffs, easier reviews, and fewer conflicts.
Q: What is the recommended workflow for keeping a feature branch up-to-date? A: Regularly merge main into your feature branch (git merge main) or rebase your branch onto main (git rebase main). This prevents large divergence and catches conflicts early while they're small.
Q: Should you commit directly to main? A: In team environments, no. Work should happen on feature branches and be merged via pull requests. This enables code review, CI checks, and discussion before changes reach the main branch.