Feature-Branching Defers Work

To quote Homer Simpson: "Did we lose a war?"

I thought we licked this problem in the aughts and early teens. Maybe it was just Seattle or maybe I'm projecting personal victories onto the industry at large.

For some reason, feature-branching is all the rage, again.

Let's go through the reasoning for feature-branches...

1. I have to make a certain number of changes.
2. I have to merge all those changes into the main branch.
3. Other people are making changes.
4. Merging changes can be difficult, especially when there are a large number of conflicts.

The feature-branching answer to those forces is basically "I'll do the hard thing a lot less often and have it be a lot more work and risk each time. You know... for efficiency or something."

When has it ever been a good thing to need to make a lot of changes all at once? What's the other case in software development where that's true?

Some people would reply "Just be disciplined about merging from master" and I can see why you might make that argument but there's a huge hole in it.

In order for that argument to make any sense at all, you need to have zero coworkers doing what you are doing (feature-branching). Otherwise, you are periodically experiencing enormous impulses of code change on your branch.

If you don't have anyone else working on your code, then you don't need to branch to shelter yourself from their changes or vice versa. If you do have other people working on your code, then branching provides the illusion of shelter while actually being a way to turn many small, easy-to-merge changes into a few large, hard-to-merge changes.

NOTE

I'm not referring to open source projects, where feature branches are used as a mechanism to control who can make a change at all.