Feature Branch Workflow: How Team Projects Work 🔀

Feature Branch Workflow is a team development approach where every task is done in a separate branch. It’s the most popular workflow in modern teams.

The Problem Without Branches

Imagine a team of three developers all working in main:

Morning:
  Ivan   — adding a login form
  Maria  — fixing a bug in the cart
  Alexey — building a new page

Lunch:
  Ivan pushes → breaks Maria's code
  Maria pushes → conflicts with Ivan
  Alexey watches the chaos → can't work

Result: No one can work properly, main is constantly broken.

The Solution: Each Task Gets Its Own Branch

main  ──────────────────────────────────────────→

         Ivan: feature/login
              ──●──●──●──●──→ PR → merge

         Maria: fix/cart-bug
                   ──●──●──→ PR → merge

         Alexey: feature/catalog
                      ──●──●──●──→ PR → merge

Everyone works independently. main is stable and always ready to deploy.

The Full Workflow

1. Start with an up-to-date main

git checkout main
git pull origin main  # get the latest changes

In GitHub Desktop: switch to main → Fetch origin → Pull.

2. Create a branch

git checkout -b feature/user-profile

In GitHub Desktop: Branch → New Branch → name your branch.

Naming conventions:

3. Work and commit

# Done part of the work
git add .
git commit -m "feat: add profile page"

# More changes
git commit -m "feat: avatar upload"

# Fixed something
git commit -m "fix: username validation"

4. Push the branch

git push origin feature/user-profile

In GitHub Desktop: Push origin (or Publish branch on first push).

5. Create a Pull Request

GitHub will show a banner: “Compare & pull request”. Click it.

Fill in the description:
- What was done
- Why
- How to test

6. Go through code review

Reviewer looks at the code and leaves comments.
You make changes and push — the PR updates.

7. Merge and delete the branch

After Approve: Merge pull request → Delete branch.

# Locally: switch to main and update
git checkout main
git pull origin main
git branch -d feature/user-profile  # delete local branch

Multiple Tasks in Parallel

The main strength of Feature Branches is handling several tasks simultaneously:

# Working on the login feature
git checkout feature/login

# A critical bug came in — switch over
git checkout main
git checkout -b fix/critical-bug

# Fixed the bug, merged via PR
# Back to the login feature — nothing lost
git checkout feature/login

Without branches you’d have to stash or revert unfinished work.

Branch Lifecycle

Created from main  →  Work  →  PR  →  Review  →  Merge  →  Deleted
     ↑                                               ↓
     └──────────── Review fixes ←────────────────────┘

A branch lives exactly as long as it’s needed. After merge — it’s deleted.

What If main Updated While I Was Working?

Another developer merged their PR while you were working in your branch.
You need to update your branch:

git checkout feature/my-feature
git merge main  # pull updates from main into your branch

In GitHub Desktop: Branch → Update from default branch.

If there’s a conflict — see the article Resolving Merge Conflicts.

Rules of Good Practice

Small branches ✅

feature/add-email-field  → 50 lines changed → 1 hour of review

vs

feature/redesign-everything → 3000 lines → reviewer cries

Small PRs get merged faster. Large ones “hang” for weeks.

One task — one branch ✅

# Good: each task in its own branch
feature/add-login
feature/add-registration
fix/password-validation

# Bad: everything in one branch
feature/auth-system  # login, registration, fix, and refactoring all in one...

Descriptive branch names ✅

The branch name should make its purpose clear:

✅ feature/user-avatar-upload
✅ fix/cart-total-calculation
❌ my-branch
❌ test
❌ new-stuff

Feature Branch in Different Teams

GitHub Flow (simple)

main → feature branch → PR → merge into main → deploy

Used in most small teams and open source projects.

Git Flow (complex)

main → develop → feature → develop → release → main

Used in teams with defined release cycles.

For learning and most projects, GitHub Flow is sufficient.

Summary

Feature Branch Workflow means:

1. Isolation — each task in its own branch
2. Stability — main always works
3. Review — code is checked before merge
4. History — clear record of what was added and when

This is the approach used at most tech companies worldwide — from small startups to Google and Microsoft.