[Updated 8.32pm]: added some narration in the middle.

There are different branch management patterns. One that's often used is Development on Trunk. It suggest that new development is done on the Trunk.

Another pattern is Stemming which suggest that there should only be 2 branches; a Stem and Trunk.

[Updated 8.26pm] A technique that's most popular to larger projects is Feature branching.

Feature Branch pattern is another branch management pattern that offers the most flexibility out of the other patterns but requires great discipline and most complex to operate.

The idea of the feature branch pattern is:

1. to have every (team of) Developers working on their respective feature branches.
2. The feature that is ready for deployment will be merged to the trunk.
3. Bugfix is treated the same way as a feature; bugfix is done on a branch and merged when it's ready for release.

Normally every branches is controlled by a smaller team or even an individual. Individual/personal branches is made possible by Distributed Version Control System (DVCS) like Mercurial and GIT.

[Note] Here is a great tutorial to DVCS and Mercurial by Joel Spolsky: HG Init.

Every feature branch also ideally have its own Continuous Integration (CI) process.

For large projects with many contributor and flexible timeline

This pattern is suitable for larger product developments which consists of large feature sets. Often there are also dependencies within them, so areas can't be treated as independent smaller projects. There are also benefits on keeping the dependencies fairly close (all areas are stored in 1 codebase, 1 solution) in order to increase reusability.

Going down this route demands rigid release planning. Which means it's hard to hold off to a specific feature, just plainly because it's already checked in.

Even when an on/off switch is built in on to every feature, theoretically, ’˜what can go wrong will go wrong'. We want to minimize the things that can go wrong, by only merging in the code that we want to release.

Most large open source projects uses this technique; which is also known as committing a patch.

Often, there is a team who is responsible for integrating feature branch into the main branch.

Before a release, the amalgamation of feature will be tested as a group.

The downside

The extra level of isolation comes at a cost; Code reusability tend to be lower than when adopting other branching strategy. However, this could be addressed by (guess what)..by talking!Having efficient communication between and among the teams helps regardless of the branching pattern that you use, but it's even more crucial here.

Merging alot of branches are difficult! Extra effort can be put to partition and segregate the solution as best as possible to minimize the impact, but there are no fast and hard tool to confirm whether there'll be issues upon merging.

This is apparently changed by using Distributed Version Control System (read post by Spolsky: Subversion re-education; Thanks to Endy Muhardin for the link).

seo tools
pagerank checker
pr checker
website ranking
google rank
rank checker
pagerank check
backlinks checker
check pagerank
check backlinks
google pagerank
google ranking
keyword density
link checker
keywords tool
website ranking