The purpose of this article is to explain how to properly employ branching.
The most important point to remember about branch design is that branches are not primarily what you should be thinking about. Branches only exist to implement the mechanics for what you ought to be thinking about: How should the development activities be organized, and how should work products (i.e., changes to the workspace) be transferred between the individuals working on the project? If you can answer that question, the technical aspects of implementing it in a branch design is very easy.
That said, it should be clear that what we can cover here is limited in the sense that the question of branch organization is very much a project-specific decision. Principles can guide the process, but only an individual thinking about the particular situation can apply the principles.
What do we mean when we say "development activities"? What are the basic units of this subject? Development activities include everything that is done by a development team or set of development teams in order to complete a project. But the work is always done by individuals. Any work product of the team must be made up of smaller units of work that were done by an individual.
In software development, these smaller units are changes to the individual's workspace that result in the completion of a given goal. You work for a while, changing a line here, adding a method there, etc., until you achieve a result that you had in mind when you initially set out in making the changes, or that became evident while working on a different change (a goal can be implicit and identified retrospectively). In OurayCM, after achieving your goal, you would normally run 'ocm save' to create a Save version on your individual branch.
All development activities are comprised of individual work like this, so organizing the development activities just means organizing these individual-level work elements, represented in OurayCM as versions on individual branches.
If we thought about the work only in terms of these individual mini-steps, most projects, especially complex ones involving lots of people, would be incomprehensible. An individual might have dozens of different small goals he works toward in a given day; there may be thousands of small goals achieved on a large project in a given day. Likewise, coordination of all these little goals so that they ultimately added up to achieving the overall project objectives would be impossible. And actually, these little goals come from broader goals: an individual is working on one of his small goals in order to accomplish some bigger goal he has been assigned. I.e., there is a hierarchy of goals involved in translating an overall project goal into individual goals. It is this hierarchy that determines the branching structure you need. Identify it and you've virtually identified your branching structure.
Consider a two-man team, Eric and Martin, working toward the release of a given system (they are not maintaining old releases). A branching structure that would perfectly reflect their work hierarchy might look like this:
A way to convey the same hierarchy in text is to list the branches:
The versions on Eric's branch are those that achieved certain goals Eric had. Some of those versions met team goals (whether explictly identified previously or not), so he submitted them to the (shared) team branch, which allowed Martin to combine his efforts and again submit, taking the team a further step toward its overall objective.
More complex branching structures come about because the goal hierarchy becomes more complex. For example, suppose Eric's work had grown in scope, and he had two junior developers (Jim and Dave) working for him. Eric was charged with assigning their work, and approving it before the work was submitted to the entire team. A branching structure that would accomplish this purpose might look like this:
Eric's team works as a team within a team, sharing work between /erics_team. When Eric thinks they've got something good, he submits their work from /erics_team to /.
To pick another example, suppose that Martin has been tasked to work on two different platforms: Windows and Linux. A typical goal might be to add a feature in Windows, and then verify that it works under Linux before making it available to the rest of the team. There are three basic goals here: 1) Add a feature in Windows; 2) Validate and correct the feature in Linux; 3) The overall goal; the combination of 2 & 3. This would be reflected in the above branch structure like this:
An example of Martin using his branches: He works in /martin/windows for a while, partly adding a feature, and then submits to /martin. He updates from /martin to /martin/linux to finish adding the feature, submitting back to /martin. He switches back to /martin/windows, gets an update and validates everything, and then submits his changes to / since everything works in both environments. Then he starts working on the next feature in a similar way (and if he ever stops needing to support both platforms, he switches back to a single-branch method).
This basic idea can be applied to teams of any complexity and to countless different purposes.
If branches are easy to think about in principle, but hard to use in practice, then they will only be used inconsistently or not at all. Use of branching will seem more like a tradeoff than a positive value, a necessary evil and not a clear-cut benefit.
Unfortunately, many SCM tools put you into this uncomfortable state of tension about branches. You want the isolation that branches provide, but not the pain that comes from using branching in that tool. OurayCM was born out of this tension. Our view is that an idea that is that good in theory must also be good in practice, as long as it is implemented correctly. In OurayCM, branches are implemented right.
This does not imply that you can create pointless branches or bogus branch hierarchies and OurayCM will magically erase the ill effects of these poor design choices. What it means is that you can think rationally about your development process, and you can count on the tool to efficiently support your intelligent design decisions instead of working against them. You can think about how things ought to be and then actually make them that way.
If you have any feedback on this article, feel free to email the author.