This chapter will explain how to work with multiple branches. We will continue to build on the simplistic setup of the previous chapter—working solo on a private project, which exists only on your computer. We will add to that a new angle, using multiple branches instead of just one.
In a solo project, using multiple branches opens many interesting new possibilities. This can greatly improve your productivity and change the way you work. In larger projects, with many collaborators, using branches is absolutely essential, as it is the primary way of combining efforts.
The following topics will be covered in this chapter:
- What is a branch?
- What you can do with branches
- Why use more than one branch
- Understanding core terms
- Using a shared repository
- Basic branching and merging
- Using the
branchcommand - Viewing basic branch information
- Comparing branches
- Merging branches
- Mirroring branches
In Bazaar, a branch is an ordered set of revisions up to a specific latest revision, commonly called the
tip. In the most simple cases, revisions follow one another in a timely order. In such cases, there is only one branch and the history is linear.
However, working in a linear manner can be limiting. Branches make it possible to work on different tasks, or different implementations of the same task at the same time. This effectively makes the history non-linear, bringing many practical benefits.
If you think of a project as a story, a branch is like an alternative ending. At any time, you can create a branch based on any of the revisions in the history, and start working in a different direction.
When working on a single branch, revisions simply follow one another in a timely order, resulting in a linear history:
This is a simple, well understood way of working, but it can be limiting sometimes. It is natural to have multiple versions of a project existing simultaneously, for example stable and unstable, with different changes going into both in parallel. However, this is not possible using a linear history.
When working on multiple branches, the revision history diverges in different directions:
After revision 2 a new branch was started (adding revisions 3' and 4'), then after revision 3 of the first branch, yet another branch was started (adding revisions 4", 5",...), and so on. At this point, the project has 4 branches, and therefore 4 possible latest revisions: 4, 4', 6'' and 6'''.
The rule of numbering revisions is still the same—when recording a new revision in a branch, increment the last revision number by one. Revision numbers are unique per branch, but they are not unique globally in the project. As such, at this point it is not clear what is the latest version of the project.
Using multiple active branches in parallel for different purposes is very common, for example, to separate the stable and unstable versions of a project, or to work on multiple features and bug fixes at the same time, but isolated from each other.
When merging a branch into another, the historical ordering of the merged revisions is preserved, resulting in a non-linear history:
The project diverged after revision 2—while work continued in the first branch, a different set of changes started in another branch. After revision 5, the first branch merged from the second branch, recording this change as revision 6. As a result, the history of the first branch is no longer linear, as now it includes the unique revisions of the other branch with their historical ordering preserved.
To keep revision numbers
unique within the first branch, the merged revisions were renamed using a dotted notation instead of simply an integer—revisions 3' and 4' in the second branch were renamed to 2.1.1 and 2.1.2, respectively, in the first branch. This numbering logic will be explained in detail later in this chapter.
