[Ummm ... don't I have this blogged somewhere else already?]
Ummm ... no.
Reasons not to:
- It can discourage refactoring. Merges involving a refactoring on one side (let alone both sides) of the equation can be bad. Discouraging refactoring is worse.
- It can frustrate CI. A good CI box should be able to bob and weave through a branch, but throwing many branches at it can cause at least the admin of the box some headaches. Discouraging CI is worse.
- Probably the motivation for feature branches is to attempt to give mgmt the ability to cherry pick features for a release. Cherry picking features is inherently complex no matter what tool you use. Branching is a bad tool for that case.
- Merging merging merging. Discouraging merging is good.
But I still want to. It'll only be small changes ... the changes between branches won't even overlap!If they won't overlap then you can devise ways to turn features on and off within the code base.
But that'll be hard!Branching is seductive because it's easy to setup and conceive of and the freedom enjoyed on each branch in isolation at the start of work is wonderful. But you're just postponing and compounding debt. Come merge time, have fun.
What's hard is cherry picking features. If you're going to do it, use a better tool than version control.
And before you get into cherry picking, you _really_ need to be asking this question: Are my quality processes robust enough to handle the unpredictable combination testing that can arise from cherry picking in the first place?
tags:
ComputersAndTechnology