About branches
A branch is a separate line of development that uses an existing repository and the files in it as a starting point. When a branch is created, files in both branches are identical. As file contents change, the branched files become different from each other.
Use branches when you need to make changes to source files without affecting existing files. When you branch a repository, changes can be promoted to or rebased from associated branches.
Surround SCM includes mainline, baseline, workspace, and snapshot branches.
Icons indicate the branch type and status. See Branch status icons
A mainline branch is the top-level branch that contains all source files, labels, other branches, and repositories. An administrative user is generally responsible for creating mainline branches. At least one mainline branch must be created before files can be added to Surround SCM. Files cannot be shared across mainline branches. See Creating mainline branches.
A baseline branch is a public branch used for collaborative development. Allowing check outs on a baseline branch lets all users directly check out and make changes to the baseline code. Changes made to the baseline branch affect everyone who accesses that branch.
Create a baseline branch whenever it is necessary to make separate changes to the code in the mainline branch. For example, your company develops software and a customer requires a feature to integrate with another vendor’s reporting tool. Create a baseline branch so you can customize the software for that customer without affecting all customers.
Baseline branches are generally created at the feature freeze (when feature development for the next release is complete) and code freeze (when the product is ready for review) milestones.
A workspace branch is a private branch used to track and isolate changes made by one user. Users create their own workspace branches. The branch that a workspace is created from is its parent branch. Other users are not affected by any changes made because the work done in the private branch. When a user finishes making changes, changes are promoted from the workspace branch to the baseline, or parent, branch. Changes can also be rebased from the baseline branch to a workspace branch.
Create a workspace branch to work on bug fixes, work on new features individually, experiment with files, or perform research without affecting other users. For example, Suzy creates a workspace branch to fix bugs. When she finishes the fixes, she promotes her changes to the baseline branch and moves on to development for the next release.
A snapshot branch is a read-only, static branch that generally corresponds to a project milestone, such as a QA build or final release. Most Surround SCM actions, such as check out, check in, and merges, are not available in snapshot branches.
Create a snapshot branch when you need to capture the state of files and the repository structure at a moment in time. For example, you may create a snapshot branch for different builds, such as alpha and beta testing, final releases, or to record custom code delivered to a customer. This can help you tell exactly which versions of files went into a build.
For example, Greg is doing daily development builds. He creates a snapshot branch after each successful build to help detect differences between builds. Snapshot branches also provide an easy way to retrieve code used in older builds. You can create a snapshot branch based on the latest file version, latest version in a specific workflow state, a label, or a timestamp.