Product InfoCustomer TestimonialsConcept and Reference DocumentsLicensing Terms and PricingCompany Location, Mission and VisionAnnouncements & NewslettersHome

Branching and Merging Strategies

Branching and merging you've heard of it, perhaps you somehow feel like you need it (or at least ought to understand it better), and you've listened to many stories about it, some good, some not so good. Nevertheless, if you are like many folks, you are not particularly comfortable with it.  Below, we present a simple way to understand branching and merging, we look at typical uses of branches, and we examine strategies to avoid, or reduce the cost of, branching and merging.

Understanding Branching and Merging

A co-worker once suggested that one could simplify one's thinking about version control by ignoring efficiency and envisioning the process in terms of simple operations on files and directories. His suggestion enabled us to focus on what we wanted to accomplish from a conceptual standpoint rather than from the vantage point of how to go about it. When applied to tagging, branching and merging, this strategy results in great simplification. Consider these tasks and how simply a basic file copy accomplishes each:

  1. Task: Preserve the state of the project files.
    Simple Action: Make a copy of the project file hierarchy to be preserved.
  2. Task: Make changes to the project files without immediately making them visible to all others on the team.
    Simple Action: Make a private copy of the project file hierarchy to be modified then incorporate the changes into the private copy.
  3. Task: Share private changes with other users.
    Simple Action: Copy the changed files from your private copy to a public copy.
  4. Task: Get changes from another user for your use.
    Simple Action: Copy the changed files from the public copy to your private copy.

From this example, we see that the version control operations of preserving, isolating and merging (or sharing) changes are variations of the basic copy operation. Yet while they all involve copying, their details and purposes vary.

These four operations (preserve, isolate, publish and subscribe, or more traditionally tag, branch, release and merge) provide a higher-level language to describe the nature of the copy. However, even these four operations are often performed at a lower level than we want.

In the next section, we look at higher-level ways of looking at branches.

Abstracting Branches

We define a branch as a copy of the project, one that was created for a purpose. A branch is not made in a vacuum but rather as a copy of an existing branch. In the making of the copy, we establish a relationship between the original and the new branches. Types of relationships include parent-child and sibling-sibling. Several uses of branches are listed and discussed below.

As you can see, there are a number of uses for branches. Understanding these high-level branch concepts will help you create an effective branching strategy for your specific needs.

Branching Advice

Branching adds complexity and overhead to development. Frequently, that overhead enables activities that justify the added complexity and expense. And many times, the branching overhead is actually less expensive than its alternatives. In either case, there are sometimes steps you can take to further reduce your branching overhead. Here are some you should consider.

Your Solution

How does your solution compare? Can you easily branch, merge and compare branches? Can you easily make release branches, patch branches, etc? Are you scared to branch because you fear merging? Do you wish this anxiety were not so?

SnapshotCM delivers a visual environment where project-level branching is trivial and where project-level comparison and merging are fast and efficient. Many of our customers have dozens or even hundreds of branches and releases. They all rely on SnapshotCM to keep it simple for them. Check us out by taking advantage of our free evaluation. Go to for all the details.