Feature Branch Workflow – The Standard Team Git Workflow

What Is the Feature Branch Workflow?

The workflow has three non-negotiable rules:

1. main is always deployable — every commit on main could theoretically be deployed to production right now
2. No direct commits to main — all changes go through a branch and a pull request
3. PRs require code review and CI checks before merging

Everything else — how you name branches, how many reviewers a PR needs, squash vs merge commits — is team convention built on top of these three rules.

Core Rules Explained

Step-by-Step Workflow

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

# Step 2: Create a descriptive feature branch
git switch -c feature/user-profile-page

# Step 3: Work on the feature — commit early and often
git add src/pages/UserProfile.js
git commit -m "feat(profile): add user profile page skeleton"

git add src/pages/UserProfile.js src/api/users.js
git commit -m "feat(profile): connect profile page to users API"

git add src/pages/UserProfile.css
git commit -m "style(profile): add responsive layout for profile page"

# Step 4: Keep your branch up to date with main to avoid big conflicts
git fetch origin
git rebase origin/main  # or: git merge origin/main

# Step 5: Push your branch to the remote
git push -u origin feature/user-profile-page
# -u sets the upstream — future pushes only need: git push

# Step 6: Open a Pull Request on GitHub/GitLab
# - Write a clear PR title and description
# - Link to the related issue (#42)
# - Request reviewers
# CI/CD automatically runs tests on your branch

# Step 7: Address review comments
git add src/pages/UserProfile.js
git commit -m "fix(profile): address code review feedback"
git push

# Step 8: After PR is approved and CI passes — merge!
# (Done via GitHub/GitLab UI — squash merge or regular merge)

# Step 9: Clean up — delete the feature branch
git switch main
git pull origin main
git branch -d feature/user-profile-page

Branch Naming Conventions

Consistent branch naming helps the whole team understand what's being worked on at a glance:

The Pull Request Process

A good pull request makes the reviewer's job easy:

• Title: short, imperative mood — "Add user profile page" (not "Added" or "Adding")
• Description: what changed, why, how to test it, screenshots for UI changes
• Link to issue: "Closes #42" in the description auto-closes the issue on merge
• Small scope: a PR should do one thing — a 500-line PR is hard to review; ten 50-line PRs are much better
• CI/CD must pass: never merge a red PR

Trunk-Based Development — The Even Simpler Version

Trunk-based development is a variation where feature branches are extremely short-lived (less than a day) or developers commit directly to main using feature flags to hide incomplete features from users:

// Feature flag pattern — incomplete feature is in main but hidden
if (featureFlags.isEnabled('new-dashboard')) {
  return <NewDashboard />;
}
return <OldDashboard />;

Workflow Comparison

The Feature Branch Workflow, Step by Step

This is the workflow most teams use: main always stays deployable, and every piece of work happens on its own short-lived branch that merges back via a pull request. No one commits directly to main.

# 1. start fresh from up-to-date main
git switch main
git pull

# 2. branch for the task
git switch -c feature/user-search

# 3. work in small commits
git add . && git commit -m "feat: add search box"

# 4. push and open a pull request
git push -u origin feature/user-search

# 5. after review + CI pass, merge to main, then delete the branch

What makes it work: the pull request is a quality gate — teammates review the diff and CI runs tests before anything reaches main, so the main line stays releasable at all times. Keep branches small and short-lived: a branch open for weeks drifts from main and merges painfully. If main moves while you work, git pull then merge (or rebase) it into your branch early to resolve conflicts in small pieces rather than one giant clash at the end.

Interview Questions

• What is the feature-branch workflow?
• Why isolate work in branches?
• What state should main always be in?
• What is the role of Pull Requests in this workflow?
• Why delete branches after merging?

Related Topics