Feature Branch Workflow

The Hook (The "Byte-Sized" Intro)

The feature branch workflow is the backbone of modern software development. It's simple: every new feature, bugfix, or experiment gets its own branch. When it's ready, it goes through a PR. When it's merged, the branch dies. This pattern keeps main stable, enables parallel work, and makes rollbacks trivial. Every team at Google, Meta, and Stripe uses some version of this.

📖 What is the Feature Branch Workflow?

The feature branch workflow isolates each piece of work in its own branch, keeping main always deployable. Developers create short-lived branches, commit their work, push, open a PR, get reviewed, and merge — then delete the branch.

Conceptual Clarity

The lifecycle:

Step	Action	Why
1	Pull latest `main`	Start from the freshest code
2	Create feature branch	Isolate your changes
3	Commit incrementally	Small commits = easy reviews
4	Push and open PR	Start the review process
5	Address feedback	Iterate with the team
6	Merge to `main`	Ship the feature
7	Delete the branch	Clean up

Rules:

main is always stable — never commit directly to it
One branch = one feature (don't mix concerns)
Keep branches short-lived (days, not weeks)
Every merge goes through a PR

Real-Life Analogy

Feature branches are like test kitchens in a restaurant. Each new dish gets its own station. Chefs experiment, taste, adjust, and perfect. Only when the dish is approved by the head chef does it go on the main menu. The main kitchen never serves an unfinished experiment.

Visual Architecture

gitGraph commit id: "v1.0" branch feature/search checkout feature/search commit id: "Add search UI" commit id: "Add search API" commit id: "Add tests" checkout main merge feature/search id: "PR #15 merged" branch bugfix/nav-crash checkout bugfix/nav-crash commit id: "Fix null check" checkout main merge bugfix/nav-crash id: "PR #16 merged" commit id: "v1.1"

Why It Matters

Stability: main is always production-ready — no half-finished features.
Parallel work: Multiple developers work simultaneously without stepping on each other.
Easy rollbacks: If a feature causes issues, revert the single merge commit.
Review-friendly: Each PR is focused on one feature — reviewers know exactly what to look at.

Code

bash

# ─── Complete feature branch workflow ───

# Step 1: Start from latest main
git switch main
git pull origin main

# Step 2: Create feature branch
git switch -c feature/user-dashboard

# Step 3: Develop (small, incremental commits)
git add src/dashboard.js
git commit -m "Add dashboard layout"

git add src/dashboard.css
git commit -m "Style dashboard components"

git add tests/dashboard.test.js
git commit -m "Add dashboard unit tests"

# Step 4: Push and open PR
git push -u origin feature/user-dashboard
# Open PR on GitHub (or: gh pr create)

# Step 5: Address review feedback
git add .
git commit -m "Fix accessibility issues per review"
git push

# Step 6: After approval — merge via GitHub UI or CLI
gh pr merge --squash --delete-branch

# Step 7: Clean up locally
git switch main
git pull origin main
git branch -d feature/user-dashboard

Key Takeaways

The feature branch workflow: branch → commit → push → PR → merge → delete.
main stays stable because nothing merges without a PR and review.
Keep branches short-lived and focused on a single feature or fix.
Clean up merged branches immediately — both local and remote.

Interview Prep

Q: What is the feature branch workflow? A: A collaboration pattern where every feature, bugfix, or task is developed on its own branch. When complete, the branch is merged into main through a pull request after review. The branch is then deleted.
Q: Why should main never receive direct commits? A: Direct commits bypass code review and CI checks, risking untested or buggy code in production. Using feature branches ensures every change is reviewed, tested, and approved before reaching main.
Q: How do you handle a situation where your feature branch has gotten too large? A: Break it into smaller PRs. You can create stacked branches (feature-part-1, feature-part-2) that build on each other, or refactor to merge smaller, independent pieces first. Aim for PRs under 400 lines of diff.