Feature Branch

Programs consist of text files that many people edit together. So that nobody gets in each other’s way while doing so, developers manage their program code with a program that records every change and can restore older states. Such a management program can maintain several parallel working states of a project. A feature branch is one such parallel working state, created for a single new function. So one mentally copies the entire project, builds, say, a search function into the copy, and leaves the official state of the project untouched. Only once the new function works are both states reunited.

Why teams don’t work directly on the main state

The official state of a project is usually called “main”. The version that customers use is built from it. It must therefore work at all times. Half-finished program code would jeopardize that.

Feature branches solve this problem because experiments take place in a separated area. A developer can break something without blocking colleagues' work. If an idea leads to nothing, the branch is simply deleted. Nothing of the attempt remains in the official state.

A second advantage is control. Because all changes for one feature are collected in one place, a colleague can read through them in one go at the end. This review is called code review. In many companies it is mandatory before anything is allowed into the main state.

From branching off to merging

At the beginning comes branching off. The developer takes the current main state as the starting point and gives the new branch a descriptive name, such as “search-filter”. From then on, they work only there. Every saved change lands as its own step in the history of that branch.

Once the feature is finished, merging follows, known in jargon as a merge. The management program compares both states and incorporates the new lines into the main state. Usually this happens automatically. But if two people have changed the same line differently, a conflict arises, and a human must decide which version applies.

That’s why there’s a rule of thumb: feature branches should be small and short-lived. Anyone who works separately for three months ends up with hundreds of conflicts. Many teams therefore regularly pull the latest changes from the main state into their branch. This keeps the gap small, and merging stays harmless.

Pull requests, GitHub, and everyday life in a development team

The most widespread management program for program code is called Git. Platforms such as GitHub or GitLab build a web interface on top of it. There, a branch is put up for discussion as a so-called pull request. Colleagues comment on individual lines, request changes, and eventually approve it.

In open-source projects, one can follow this process publicly. Anyone who wants to fix a bug in a free program creates a feature branch and sends a pull request. The maintainers of the project then decide whether the change is accepted. This is how large parts of the software that runs on the internet come into being.

The principle also comes up in business news when it’s about the development speed of tech companies. Frequently mentioned is the counter-approach called trunk-based development: there, everyone works almost directly on the main state and switches unfinished features to be invisible only to users. Both approaches pursue the same goal, namely frequent and low-risk releases. They differ only in how long work remains separated from the rest.