By using a dedicated branch to implement some new features or a set of related changes within the same topic, the changes can be cleanly isolated from other work in the project. This effectively eliminates side effects and instabilities caused by other unrelated changes in the project while working on the new feature.

Such dedicated branches are often called feature branches or topic branches. These terms are equivalent; for simplicity, we will use the term feature branches throughout this book.

Isolating the development of features in this way also makes the project history cleaner—when the feature branch is merged into the main branch, the revisions in the branch are grouped together under a single revision, hiding the low-level details by default.

For example, merged branches are shown collapsed in the history:

The following screenshot shows merged branches expanded to see the detailed steps:

In this way, you can get a higher level view of the history with only the larger steps, and can drill down into more details as needed. This also allows rolling back a feature by reverting a single revision that performed the merge.

When you work on different features or topics in separate dedicated branches, you can easily switch between tasks when needed. For example, if you are in the middle of developing a new feature but suddenly something more important comes up, then you can suspend your work in progress and switch to the urgent task. Once the urgent task is completed, you can return to your previous task and continue where you left off from:

You can switch back-and-forth between multiple tasks in this way, develop them gradually through multiple commits, and when a feature is completed, you can merge it into the main branch of the project.

In the same way that you can work on multiple features using multiple dedicated branches, you can also try different implementations of the same feature and split them into multiple branches.

Another typical situation is when in the middle of working on a feature, you realize that your last few commits may be going in the wrong direction and a different approach might be better. When this happens, you don't have to throw away what you've done so far; it is much better to create a new branch based on the last revision you were still happy with, and try a different approach in that new branch:

If at a later stage you realize that your first approach was not so bad after all, you can still return to it easily at any time.

In projects with ongoing development and stable milestone releases, using multiple branches is inevitable in order to maintain multiple versions in parallel. In addition to the main branch with ongoing development, typically at least one more branch is needed for the occasional maintenance work and bug fixes on the last stable release.

For example, if a critical bug is discovered that needs to be fixed and released urgently, then using the main development branch is usually not an option, as it typically contains many changes that have not been thoroughly tested yet. One good solution in such situations is to keep a separate branch for the last stable release, ready to receive bug fixes and to be rereleased at a minimal risk of side effects.

In sufficiently large projects, multiple branches are essential for maintaining the stable lifecycle of the project and to manage its releases.