Feature Branch Workflow
The feature branch workflow is less a Git feature and more a convention teams adopt on top of ordinary branching and merging. The core rule is simple: main (or master, or trunk) always represents working, deployable code, and no one commits to it directly. Every unit of work — a new feature, a bug fix, a chore — gets its own branch created from the latest main, named descriptively, and worked on in isolation. When the work is done, the branch is pushed and opened as a pull request; only after review and passing checks does it get merged back into main. This isolates in-progress, potentially broken code from the branch everyone else builds on and deploys from, and it gives every change a natural checkpoint for review.
Cricket analogy: Like keeping the Test XI's main squad list untouched until a player proves themselves in domestic cricket first — Virat Kohli's spot on main stays secure while a young batter like Yashasvi Jaiswal builds his case on a separate net-session track before selectors merge him in.
Branch naming and scope
Most teams standardize a naming scheme such as feature/<short-description>, fix/<short-description>, or <ticket-id>-<short-description> (e.g. PROJ-482-rate-limiting) so that branch lists and CI dashboards are self-explanatory at a glance. Scope discipline matters as much as naming: a feature branch should correspond to one reviewable unit of work. Branches that live for weeks and accumulate unrelated commits become painful to review and prone to conflicts, which is why the workflow is often paired with the advice to keep branches short-lived — ideally merged within days, not weeks.
Cricket analogy: Like labeling net sessions by purpose — "spin-practice-Ashwin" or "yorker-drill-Bumrah" — so the coaching staff knows at a glance what each session covers, and keeping each session focused on one skill rather than dragging on for a whole season.
# Start a new feature branch from an up-to-date main
git checkout main
git pull origin main
git checkout -b feature/csv-export
# Work, commit incrementally
git add src/export/csv_writer.py
git commit -m "Add streaming CSV writer for large export jobs"
# Keep the branch current with main as it moves
git fetch origin
git rebase origin/main
# Push and open for review
git push -u origin feature/csv-export
# After merge, clean up locally
git checkout main
git pull origin main
git branch -d feature/csv-exportKeeping branches in sync
The longer a feature branch diverges from main, the more likely it collides with other people's merged work. Two strategies address this: periodically merging main into the feature branch (safe, but adds merge commits to the branch's history) or rebasing the feature branch onto main (rewrites the branch's commits on top of the latest main, producing a cleaner linear history but requiring a force-push since the branch's history changed). Teams typically pick one convention and apply it consistently; rebasing is common for solo feature branches that haven't been shared, while merging is safer once collaborators are also pushing to the same branch.
Cricket analogy: Like a batsman periodically checking the scoreboard and adjusting his running between wickets (merging) versus a captain redoing the entire batting order fresh each innings for a cleaner strategy (rebasing), which only works if the order hasn't been announced to the opposition yet.
The feature branch workflow scales down to solo projects and up to large teams unchanged — the only thing that grows is the sophistication of the review and CI gates attached to the pull request step, not the branching model itself.
Rebasing a feature branch that other collaborators have already pulled and built on top of rewrites shared history; anyone who pulled the old commits will get confusing duplicate commits or conflicts. Only rebase branches that are effectively yours alone, or coordinate explicitly first.
- Main always stays deployable; all work happens on branches created from it.
- Descriptive, consistent branch names (feature/, fix/, ticket-id-based) make history and CI dashboards self-explanatory.
- Short-lived, narrowly scoped branches are far easier to review and merge than long-running sprawling ones.
- Syncing a feature branch with main can be done via merge (safe for shared branches) or rebase (cleaner history, requires force-push).
- The workflow pairs naturally with pull requests as the review and merge gate.
- Never rebase a branch that collaborators have already pulled without coordinating first.
Practice what you learned
1. In the feature branch workflow, where does new work happen?
2. What is a key risk of letting a feature branch live for several weeks without syncing with main?
3. Why does rebasing a feature branch onto main typically require a force-push?
4. What is the main danger of rebasing a feature branch that teammates have already pulled?
5. Which branch naming convention best supports quick scanning of a team's open branches?
Was this page helpful?
You May Also Like
Pull Requests and Code Review
How pull requests turn a branch into a reviewable, discussable proposal for merging code, and the practices that make code review effective rather than a rubber stamp.
Creating and Switching Branches
Master the day-to-day commands for creating, switching, listing, and deleting branches, including the modern git switch/git restore split from git checkout.
Git Flow and Trunk-Based Development
Two contrasting branching strategies for organizing a team's work — Git Flow's structured long-lived branches versus trunk-based development's short-lived branches off a single trunk.
Rebasing vs Merging
Compare git rebase and git merge as two different strategies for integrating branch changes, and learn when a linear history is worth the trade-offs of rewriting commits.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics