Feature Branching

I recently made some waves on Twitter (and other circles) regarding my dislike of “Feature Branching.”

The bigger the apparent reason to branch, the more you shouldn’t branch
@jezhumble

Feature branching is a poor man’s modular architecture… you’re coupling
yourself to source control and manual merging
@DanielBodart

The quote is more powerful when not limited by character count:

“Feature branching is a poor man’s modular architecture, instead of building systems with the ability to easily swap in and out features at runtime/deploy time, you’re coupling yourself to the source control providing this mechanism through manual merging” (Daniel Bodart)
Since that time, I’ve been thinking about why I have so much pent-up anger toward feature branching:

I think my main beef with feature branching is that branches for a feature too easily turn into a long-lived, isolated, work of art that provides a set of “wonderful” merges later on… (note: a merge is not done once git says so).

< steps onto soap box >

I hate long-lived feature branches. They’re one of the most selfish things you can do as an engineer when part of a fast-moving team.

Why do I use such strong words?

The mistake you’ve made with a long-lived branch is that you’re doing your work in isolation while the world is changing around you. Said another way: while the world exists (and doesn’t stand still), you’re building a parallel world (real world + your world). Eventually, your world is going to collide with the real world (the one everyone else is in) creating a cascading merge conflict effect (and I don’t just mean git conflicts). We all know what happens when worlds collide.

A common pro-feature branch argument at this point seems to be: “It’s ok, I’m merging master in every day.”

To which, I propose: If everyone is doing work on their own long-lived feature branch and no one is merging back to master until the day before code freeze, what level of complexity have you introduced into the process of shipping all those features?

< steps down from soap box >

There are always new ways of doing branching and merging (and we’ve seen tons of branch/merge strategy ideas pop up over the years), but the fact is that a feature is not done until it’s operating (correctly) the customers’ hands. The value-exists-only-in-production worldview has rippling implications on how you engage in getting work done in a multi-engineer organization.

Choosing your branching/merging strategy is hard. There’s no right answer for every situation (company, feature, product, technology, etc.). But then again working as a team - as an organization - is hard too.

 
7
Kudos
 
7
Kudos

Now read this

ReadyTalk Pipeline DSL

If you’ve used Jenkins for any amount of time you might like its configurability and extensiblity but also understand that this flexibility poses serious drawbacks to his continued use. I feel as though Jenkins suffers mostly from a lack... Continue →