Feature branch
FEE-cher branch
A separate branch in version control where a developer builds a new feature before merging it to main.
A feature branch is a copy of the main codebase where a developer works on a specific feature in isolation. The developer creates the branch, makes changes, commits code, and eventually merges it back into main through a pull request. Other developers' work is not affected until the merge happens.
This is the most common branching strategy in software development. GitHub Flow, the workflow used by most open-source projects, is essentially: create a branch, make changes, open a PR, get it reviewed, merge. It keeps the main branch stable because unfinished work never touches it.
The risk is long-lived branches. A feature branch that lives for three weeks diverges significantly from main. Other developers merge their changes to main during that time. When the feature branch finally merges, there are conflicts. The longer the branch lives, the harder the merge. This is why trunk-based development advocates recommend very short-lived branches (hours to days, not weeks).
Examples
A developer starts working on a new feature.
The developer runs 'git checkout -b feature/user-preferences' from main. They work on the feature for two days, making 8 commits. When done, they push the branch and open a PR. A teammate reviews the code, suggests a change, the developer updates, and the PR merges. The feature branch is deleted. Total branch lifetime: 2 days.
A long-lived feature branch causes merge conflicts.
A developer works on a major refactor for three weeks in a feature branch. Meanwhile, 45 PRs merge to main. When the developer tries to merge, there are 23 files with conflicts. Resolving them takes a full day and introduces a subtle bug. The team adopts a policy: rebase feature branches against main daily to catch conflicts early and keep them small.
A team organizes branches by convention.
The team uses prefixes: feature/ for new work, fix/ for bug fixes, chore/ for maintenance. Branch names include the ticket number: feature/PROJ-123-user-preferences. This convention makes it obvious what each branch does, links to the tracking system, and helps the CI pipeline apply different rules (feature branches get full test suites, chore branches get only lint checks).
In practice
Read more on the blog
Frequently asked questions
How long should a feature branch live?
As short as possible. Ideally hours to a few days. Branches that live longer than a week have significantly higher merge conflict rates and integration risk. If a feature takes two weeks to build, break it into smaller increments that can each be merged independently. Use feature flags to hide incomplete work in production while keeping branches short.
Should you rebase or merge when updating a feature branch?
Rebase for a clean history, merge for safety. Rebasing replays your commits on top of the latest main, creating a linear history. Merging creates a merge commit that preserves the branch structure. Rebase is preferred for short-lived branches that have not been shared. Once a branch is pushed and others are reviewing it, merge is safer because rebase rewrites history and can cause problems for collaborators.
Related terms
A parallel version of the code that lets developers work on changes without affecting the main codebase.
A branching strategy where developers commit directly to main (trunk) or use very short-lived branches.
A branching model with long-lived develop and release branches alongside feature branches.
A proposal to merge code changes from one branch into another, with review.
Combining code changes from one branch into another, integrating the work.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.