How Are Branches Used?

Branches are used to allow work to be done in parallel on the same collection of files, such as for a product. One branch might be for maintenance, one for ongoing development of the next release. The last release of the product might have been developed on yet another branch. Here are some examples of how branches can be used:

• For a new feature or feature set
• For a set of bugfixes, or even one fix per branch
• For performance improvements
• For integration and stabilization
• For testing, benchmarking, or releasing

Benefits of Branching

Using a branch provides isolation from other work on the same product(s). Isolation means that the work on other branches has no effect whatsoever on your branch until you decide to merge another branch into your branch. The merge process can involve potentially many files, but when it is completed your branch will contain the essence of the changes on the other branch.

You get to decide if and when to merge your branch according to what makes sense for your project. Isolation is useful because it means the only changes you have to understand are those on your own branch. It makes troubleshooting much easier when there are fewer changes and you are more familiar with them.

Costs of Branching

Nothing valuable comes without a cost. If you branch then you will eventually have to merge. The cost of merging can be measured in time and quality. First, it takes time merge. The more changes that happen between two branches, the more time it is likely to take to merge them. Also, if there is a lot of overlapping work (changes to the same parts of the same files) the merge will be even harder.

The other cost is quality. Merging can introduce bugs just as any other kind of programming. The kinds of bugs introduced by merging are usually missing or extra lines of code, but in general merging means mixing changes you understand with changes you don't. So there is a risk that you won't properly merge the changes you don't understand.

Even so, it is easier to integrate with a branch that contains working changes than to integrate with a branch which contains many problems, where even a perfect merge is not expected to yield an operational product. So there is value in letting the work on a branch mature to a point where it is stable before merging with it.

It is a trade-off. The Branch & Merge course discusses more ideas that will help you decide whether the trade-off is a good one for your project.

Branch Mechanics

Once your project branch is defined then you can forget about it until it is time to merge. Until you merge you can pretend that you own the ClearCase directory structure. It is as if no other branches existed at all. You don't see them and you don't have to worry about branching. When you check a file out that has not been branched yet for your project, a branch is automatically created. Each time you check a file in, a new version is added to that file's sequence of versions for your project. For example, if you check a given file out and in five times then its branch for your project will have five versions. Any files not modified in your project will not be branched for your project.

Previous Page	Next Page
Versions & Branches	Elements
Course Map
Search Help