Create a baseline branch to customize software for a customer. For example, your company develops software and a customer requires a feature to integrate with another vendor’s reporting tool. Creating a baseline branch lets you customize the software for that customer without affecting all customers.
Create a workspace branch to work on bug fixes without affecting other users. For example, Suzy creates a workspace branch to fix bugs. When she is satisfied with her code, she promotes her changes to the baseline branch and moves on to development for the next software release.
Create a snapshot branch to mark the last valid build of the baseline. For example, Greg is doing daily development builds. He creates a snapshot branch after each successful build to easily detect differences between builds. It also provides an easy way to retrieve all the code used in older builds.
The following example illustrates one company’s use of branching. A mainline branch named Version 1 is created. When Version 1 is close to being released, all changes to the source files need to stop. But bug fixes and development of the next version need to continue. The solution is to create two branches from Version 1.
The first branch is named Version 1 Fix. Developers create their own workspaces from this branch and begin working on bug fixes. When developers finish bug fixes and test their code, they promote their changes to Version 1 Fix. The project lead does a code review to ensure all bugs are fixed and the code is stable. She then promotes Version 1 Fix changes to Version 1.
The second branch is named Version 1.2. Development for the next release is done in this branch. This branch becomes the baseline for all Version 1.2 development. After bug fixes are promoted from Version 1 Fix to Version 1, changes can be rebased from Version 1 to Version 1.2.
Following is another branch example. The WysiChart development team - Joe, Beth, and Alex - each work in private, workspace branches, isolated from changes until they decide to accept them. As code changes are completed and tested locally, they are promoted up to the development branch. The latest development build is always available to the team. After changes are reviewed by the team lead, they are promoted to the QA branch for testing by the SQA team. The latest quality-controlled build is always protected from the changes downstream.