Branching and Merging Anti-Patterns
Chris Birmele has only posted once, but the document he authored is a good read. The document is a tool agnostic Branching and Merging primer. Excerpt:
Using branches provides better isolation and control of individual software assets and increases productivity because teams or individuals can work in parallel. But it also implies an increase of merge activities and therefore risk because branches have to be reassembled into a whole at some point in time.
Chris goes on to describe common branching strategies, and names some anti-patterns. Some of his anti-patterns that I’ve witnessed include:
Merge Paranoia - because the company spent a massive amount of money on configuration management tools and hired three full time consultants to increase the complexity of customize the software. Branching and merging became a hugely involved effort requiring magic incantations and chicken blood. The consultants all left, and everyone left behind fainted at the sight of blood.
Development Freeze - because the company didn’t have a robust tool, and everyone had to stop development to “make sure the merge goes through”.
Berlin Wall - because we didn’t like them, and they didn’t like us. Isn’t office politics fun?