Planning a branching strategy
Branches are used to enable parallel development. A branch is an object that specifies a linear sequence of versions of an element. Every element has one main branch, which represents the principal line of development, and may have multiple subbranches, each of which represents a separate line of development. For example, a project team can use two branches concurrently: the main branch for new development work and a subbranch to fix a bug. The aggregated main branches of all elements constitutes the main branch of a code base.
Subbranches can have subbranches. For example, a project team designates a subbranch for porting a product to a different platform; the team then decides to create a bug-fixing subbranch off that porting subbranch. In an HCL VersionVault configuration, you can create complex branch hierarchies, for example, a multilevel branching hierarchy like that shown in Branching hierarchy in base VersionVault. As a project manager in such an environment, you need to ensure that developers are working on the correct branches. To do that, you must tell them which rules to include in their config specs so that their views access the appropriate set of versions.
Branching policy is influenced by the development objectives of the project and provides a mechanism to control the evolution of the code base. There are as many variations of branching policy as organizations that use HCL VersionVault version control. But there are also similarities that reflect common adherence to best practices.
- Task branches
Are short-lived, typically involve a small percentage of files, and are merged into their parent branch after the task is completed. Task branches promote accountability by leaving a permanent audit trail that associates a set of changes with a particular task; they also make it easy to identify the task artifacts, such as views and derived objects, that can be removed when they are no longer needed. If individual tasks do not require changes to the same files, it is easy to merge a task branch to its parent.
- Private development branches
Are useful when a group of developers need to make a more comprehensive set of changes on a common code base. By branching as much of the main branch as needed, developers can work in isolation as long as necessary. Merging back to the main branch can be simplified if, before merging, each developer merges the main branch to the private branch to resolve any differences there before checking in the changed files.
- Integration branches
Provide a buffer between private development branches and the main branch and can be useful if you delegate the integration task to one person, rather than making developers responsible for integrating their own work.