Reasons for Branching
Should you branch? In a nutshell, the primary reason to branch is if concurrent or parallel development must occur. This is described as the need to perform two or more isolated lines of development on the same baseline of code but for different purposes.
If there is a need for branching, a project release branch may be used to isolate the project work from the main line which may represent what is in production (therefore, you would not want to corrupt production with less than production-ready code). This is branching in its most simple form, however, there are more complex reasons for branching.
Reasons for parallel development at a project level may include (but not limited to):
- Working on two or more project releases (this may include major releases, minor release, customer specials, prototypes, platform conversions, etc.)
- Working on a project release and on bug fixes/patches for a previous release(s)
- Reasons for parallel development within a project may include (but not limited to):
- Working with other sites (site specific branch)
- Working with several colleagues at the same site (shared branch)
- Working within a private workspaces (user specific private branch)
There is no limit to the number of branches that can exist. A branch and merge strategy should be designed prior to creating branches, though, to first ensure that branching is needed and secondly to ensure that the branch structure under consideration will work for the project. Too many branches may make development too complex to follow and too few branches may constrain development.
Many project teams perform development from the trunk or main branch because they follow the serial development approach. However, some project teams end up performing some level of parallel development on the trunk or main branch and this is where problems may begin. The important point is to recognize the need for branching before and prepare a strategy for it. Conversely, many project managers make a decision to perform parallel development, but are not sufficiently informed of the complexity and effort. It is the job of the SCM professional to raise this awareness so they can understand the appropriate reasons for branching (or not branching).