mercredi 15 avril 2009

The evil of long-lived branches

Long-lived branches make good practices bad.

When coding in a branch that will eventually be merged, it's a bad idea to refactor. All the global changes required to correctly implement the feature you need to code will send lines flying all over the code base and there is no VCS capable of dealing with that automatically.

I mean, the VCS will be able to apply the changes you have made to some other codeline, but the changes done in the branched code that has been moved & refactored won't be merged properly.

Because you are on a branch, you can't code as local as possible anymore. You can't, because you won't be able to refactor when you will need to re-use this local code. You need to know in advance what will be re-used and how. That sends all those agile tricks out the window. Overdesign becomes the only solution. It means that the quality of the code is getting worse every day those branches are maintained apart. And if this situation lasts for a couple of months, it comes to a point where you don't even want the different branches to be merged anyway.

Features go in the mainline, stabilization in a short-lived regularly-merged (towards the mainline) branch. Doesn't it make sense?!

Aucun commentaire: