This article lays the foundation for a series on branching and the development management techniques it enables.

Versions and Delta

A simple linear development progresses by building one version on another. So, version one is updated to produce version two, version two is changed to make version three, and so on. This form of version progression is well understood whether the thing being controlled is a document, source file, or an entire system.

The diagram on the right shows a simple linear version line. Versions one and two are separated by the change (or delta) ‘a’. This can be read as version ’1′ with changes ‘a’ becomes version ’2′.

If all development work could be relied upon to be this linear then this would be a very short series. Fortunately for us, this simple linear model cannot be relied upon for anything but the simplest development work.

Bring on the branch

Suppose we have released version two of our product to formal user testing and have begun development of version three of the product. Formal user testing will last for at least six weeks and after that we expect that the product will be in use for some time before version three is ready.

During testing we expect to find some defects and the users will undoubtedly request some ‘fine tuning’ of version two.

This situation cannot be accommodated with the simple linear development process described above. What we need is some means to manage the corrections to version two while version three development is carried out.  Of course, any changes we make in version two must eventually be included in version three (otherwise defects corrected in version two will suddenly reappear when we release version three). However, we do not want changes made when developing version three to be included in version two maintenance (otherwise we would find partially implemented version three changes suddenly causing problems in the user test version one systems).

Basic Branch

The diagram above shows a simple branch. Our main development (the work developing version three of our product) continues, while maintenance work is branched off from version two of the product (shown above as version ‘a1′).

Any changes made between version ’2′ and ’3′ in the main line development have no effect on the branch.

The branch is used to make changes such as defect resolution during the testing of version two. Any changes on the branch (between version ‘a1′ and ‘a2′) must be integrated back into the main line development before version ’3′ is released for testing. This ensures that any defects fixed during version two testing are also fixed in version three.

Branching really is that simple. However (there’s always a ‘however’ in there somewhere), while this is schematically correct and simple, in real life things can get more complicated. I leave dealing with these complications for another day.

As always, any questions can be addressed to me directly or through the comments on this post.