ahhh, i changed 2 companies sin the past 1 year. i’m about to change another. the reason? lack of re-factoring, the daily basis casual one! can’t stress enough how vital it is, but is missing from most chart/diagrams of software processes. it must be an integrated part of development. PERIOD!

however, instead of asking how to do re-factoring and branching, the right question might be: do we need branching at all? I’ve initiated a large refactoring effort, focused, where we needed re-design the whole flow. what I did was to make a clever use of namespaces. the new changes were introduced in a separate namespace. one finished and tested the new implementation all I had to do is to rename the old one to some dull name like namespaceXXX and then rename my reafactored namespaceR back to original one: namespace.

also I’m in favor of not treating your trunk for deployments and shipping apps. use branch for each release all new features and bug fixes go to trunk, only bug-fixes got introduced in deply/ship branch.

think not 2, but 3 times before you introduce branching and whether you really need it. NEVER create unnecessary friction for you developers!

When Martin first talked about preferring toggles over feature branches there was always a feeling in the back of my mind that something here wasn’t quite so black or white. I haven’t actually used feature toggles on a project so I can’t say I had enough experience on either side to back up my feeling.

Thanks for clarifying it for me.

ps. i wrote a simple .Net feature toggle library: http://nuget.org/packages/FeatureToggle

Exactly. That’s the same rules I have in my org. Default better be deployable! Feature branches optimally should work, less-optimally should build, but it’s better to have a work in progress that’s totally failure inside a feature branch in the repo than on a dev’s machine disconnected.

Daniel