Branch (version control)

On a software project, many people often work on the same files at the same time. So that no one overwrites anyone else’s work, tools are used that record every change and keep old states around. The best-known of these is called Git. In such tools, you can branch off from the current state of the project and keep working within that branch. This branching-off is exactly what’s called a branch. The original state remains untouched, no matter how much is changed or broken within the branch.

Why teams don’t all work on the same state

Without branches, every change would have to go straight into the version everyone uses. A half-finished feature would then bring the entire project to a halt. A team of twenty developers would constantly be blocking each other. With branches, everyone works in their own branch and disturbs no one.

A second reason is safety. If an experiment goes wrong, you simply delete the branch. The main line never noticed anything. This ability to try something out without consequences changes the way of working significantly: people dare to attempt bigger overhauls, because a way back is guaranteed to exist.

Third, branches allow multiple versions to be maintained in parallel. A company can work on version 3.0 in one branch while fixing bugs in version 2.0 in another, which customers are currently using. Both states exist side by side without mixing.

Branching off, working, merging

A version control system stores the project’s history as a chain of save points. Each such point is called a commit and records which lines were changed, when, and by whom. At its core, a branch is just a pointer to one of these points. That’s why creating a branch takes practically no time at all: nothing is copied, only a new pointer is created.

If you keep working in the branch, new commits attach themselves there, and the history forks. What follows is merging, known in technical jargon as a merge. The system compares both lines of development and combines the changes into a shared state. As long as different files are affected, this happens automatically.

It gets difficult when two people have changed the same line in different ways. This is called a conflict, and then a human has to decide which version prevails. A common misconception is that such conflicts are a fault of the system. In fact, it’s the opposite: the system reliably recognizes that it isn’t allowed to make the decision itself. The longer a branch stays separated from the main line, the greater the differences become and the more laborious the merge.

Branches in GitHub projects and AI tools

Anyone looking at a project on platforms like GitHub or GitLab usually sees a main branch called main alongside a list of further branches. Typical names are feature/login or bugfix/crash-on-startup. The usual workflow: branch off, build the feature, submit the change for review, and after approval merge it back into main. This submission is called a pull request and is the place where colleagues comment on the code.

The principle also shows up outside of programming. With AI models, people speak of a fork or branch when someone takes a published model and develops it further in their own direction. Assistant systems that write code autonomously often automatically create their own branch for their suggestions. This way, the reviewed state remains protected until a human approves the suggestion.

In business news, the term itself is rarely mentioned directly, but its consequences are. When it’s reported that a company has spun off a piece of software, or that an open-source project has split into two camps, there is almost always, technically speaking, a branch behind it that was never merged back.