A feature branch is a git branch created for the development of a single feature or change, kept separate from the main branch until the work is complete and reviewed. The developer works on the branch in isolation, then opens a pull request to merge it back.

main:           A --- B --------- F  (feature merged)
                       \         /
feature/login:          C --- D --- E

The benefit is isolation: an incomplete or broken feature does not affect other developers working on main, and main stays releasable at all times. Review happens at merge time, and the branch can be discarded if the approach turns out to be wrong.

The most common failure mode of feature branching is long-lived branches. A branch that diverges from main for three weeks accumulates a large diff and becomes painful to merge. The longer the branch lives, the more conflicts accumulate and the harder it is for reviewers to understand the full change.

Short-lived feature branches (one to three days) work well. Branches that grow beyond a week often indicate the feature should be broken into smaller pieces, or that the developer should be integrating with main more frequently.

Trunk-based development is the alternative: everyone commits directly to main (or merges very short-lived branches within a day or two). Incomplete features are hidden behind feature flags rather than on a branch. This keeps integration continuous, which is one of the goals of CI/CD. Feature branches and trunk-based development are both valid strategies; the trade-off is isolation/cleanliness of main versus integration frequency.