Branch

A branch is a divergence from a shared working state. Programs consist of text files, and often many people work on these files at the same time. So that no one overwrites anyone else’s work, each person creates their own copy to tinker with on their own. This very copy is called a branch. Later, the changes from the branch are brought back into the main version, or the branch is discarded. The word is a metaphor from botany: branches grow out of a trunk and develop independently of one another.

Why teams without branches descend into chaos

Imagine twenty developers editing the same file at the same time. Each one saves whenever they want. After an hour, no one knows anymore which version is the right one. Branches solve this problem by giving each piece of work its own space. Merging only happens at the end, deliberately and in a controlled way.

The second advantage is safety. There is almost always a main branch, often called “main,” which holds the version that actually runs for users. This branch must work at all times. Risky experiments therefore happen elsewhere. If an experiment goes wrong, you simply delete the branch, and the main state remains untouched.

For companies, this is also a matter of traceability. Every change is tied to a branch, every branch to a person and a date. If a piece of software has a bug, you can trace back when it was introduced. In regulated fields such as banking or medical technology, such a trail is even required by law.

Branching off, working, merging

Managing branches is handled by version control software. By far the most widespread program for this is called Git. When you create a new branch, you don’t copy the entire project. Git only keeps track of the point in history where the branch begins and which changes have been added since then. That’s why creating a branch takes a fraction of a second, even for huge projects.

At the end comes the merging, known in technical jargon as a merge. Git compares the changes from both sides and builds a combined version out of them. Usually this works automatically, because different people have edited different parts. But if two people have changed the same line, a conflict arises. Then a human has to decide which version prevails.

A common misconception: a branch is not a backup. It doesn’t protect against data loss, but rather separates parallel working states from one another. It’s also important to distinguish it from a fork. A fork is a complete, independent copy of someone else’s project, usually with the goal of developing it further permanently as a separate project. A branch, on the other hand, usually remains part of the same project and is designed to be merged back in eventually.

From GitHub to language models

Branches are most visible on platforms like GitHub or GitLab. There, the program code of countless projects lies openly accessible on the web. Anyone who wants to contribute an improvement creates a branch and sends what’s called a pull request, i.e., a request to have the change adopted. Others read the proposal, comment on it, and either accept or reject it.

In the world of AI, the term also appears outside of pure program code. On the platform Hugging Face, a kind of library for freely available AI models, model versions are also organized in branches. So alongside the main version, you often find smaller, more resource-efficient variants of the same model. Anyone using a model should therefore know exactly which branch they’ve actually loaded.

Incidentally, the word has a second meaning in computer science as well. A branch is also a fork in program execution, i.e., an if-then decision within the processor. The context usually makes it quickly clear which meaning is intended. When it comes to teams, code management, or GitHub, it almost always refers to the development branch.