Isolating Work with Feature Branches
A feature branch is a source code branching pattern in which a developer creates a new branch from the common codebase when beginning work on a feature. All of that work happens on the branch, and the changes are merged back into the shared codebase only once the feature is considered complete.
While working on the feature, the developer may pull changes that other team members have already confirmed into her own branch. This helps reduce the scale of integration work later on. However, until the feature is finished, none of her work becomes part of the shared code. A key consequence of this approach is that two developers working on separate feature branches do not combine their efforts until one of them merges their results into the common codebase.
The Trade-offs of Deferred Integration
Feature branching is a widely used technique and is especially common in open-source development. The main benefit is that it keeps all work tied to a feature away from the team's common codebase until it is done. This defers all the risk inherent in a merge to a single, later point in time.
That isolation, though, comes with costs. It prevents the team from detecting problems early through regular integration. More significantly, working in isolation tends to discourage refactoring. A lack of refactoring over time often leads to a serious decline in the overall health of the codebase.
The impact of using feature branches depends heavily on how long it takes a team to complete a typical feature. Teams that finish features in a day or two integrate often enough to largely avoid the pitfalls of delayed integration. Teams whose features take weeks or even months to complete are far more likely to run into these difficulties.
For a deeper look, see the long-form article on Patterns for Managing Source Code Branches. That piece places feature branching in the broader context of branching in software development, details the workflow of a feature branch, discusses the trade-offs related to integration frequency, and examines Continuous Integration as an alternative.
