Enterprise vs. Startups: Different Branching Strategies

Comments

It seems version control at Enterprise level is seen very different from that in startups.

Enterprise

Enterprise is anti-branching - everything is committed to trunk, and branches are only short lived, if ever used. This thinking is presented, for example, in Martin Fowler’s article on feature toggle and Jez Humble’s Abstraction Layer article.

I don’t fully agree with the arguments presented in favour of this model. Feature Branches and Feature Toggles are not mutually exclusive - indeed, I’d use the two together. As for the Abstraction Layer, to introduce more complexity in the code to suit version control tools seems a bit back to front.

Also, it seems that the main argument always boils down to: merging branches back to trunk is hard. Yes it is - with svn. And that’s why distributed system were created.

Distrubuted

Smaller setups can benefit from feature branching. Here’s for example a policy I was involved in setting up:

  • trunk always contains a stable, signed off version of the product

  • new features are developed in branches. They are merged back to trunk when ready, with feature switches

  • automated tests, if any, are run against trunk to ensure no regression issues are introduced

  • in order to be merged back to trunk, a feature branch needs to:

    • be bug free

    • have passed manual QA

    • be signed off by ux / creative / clent

    • any automated scripts are written and ready to be added to the poll of scripts running on trunk

  • to decrease the chance of conflicts, it is recommended branches are rebased (i.e., have changes from trunk merged into it) frequently, at least daily

  • the naming convention for branches is ddd_xxxxx where ddd is a three digits number starting from 000 and increasing by one for each branch, and xxxxxx is any string that would work as a JS variable name and is relevant to the project, if possible.

A similar approach, but using git, is explained in this old but still relevant article: A successful Git branching model

Choosing between the two

Strictly speaking, it isn’t really necessary to choose - even in a corporate environment, teams or even individual developers can synchronize their own git repositories with the central svn ones. Here’s an old article about git2svn, for example.

Given the choice, I’d go for feature branching any time. But it all depends on the culture of everyone involved - developers, management, and clients.

Comments