Principles of branching in version control systems

Many developers are uneasy about branching and merging, even those who consider source control essential. It can be a very complicated process, but it doesn't have to be, and it is a very powerful way to manage development. Here's how to get started with branches in Subversion.

Principles

Branching produces a split in a code stream: different developers can be working in alternate universes of the same set of code. Changes are made independently to each stream. Merging brings changes back together to combine the streams. There are a number of reasons why you might want to use branches, and different reasons produce different kinds of branches.

Branching is a powerful tool in managing development and releases. There are many different styles of branching, but I've only ever needed two: Fixes and Features, which I'll describe below. These are simple, and fill 90% of the need for branching. Don't go overboard with elaborate branches. Purists will develop complex theories and algebras of branching, with baroque policies and criteria. It doesn't have to be complicated.

One recurring debate is over what goes on the trunk and what goes on the branch. How do you decide what work will happen on the trunk, and what will happen on the branch? Here is my rule: Branches are for the minority.

Using a branch is always more involved than using the trunk, so the trunk should be used by the majority, and the branch should belong to the minority. Subversion is easier than other source control systems in this regard, but the rule still holds: when trying to decide what goes on the trunk and what goes on the branch, put the code that most developers want on the trunk, and put the minority on the branch.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com