For what I think is the first time in my career, I’m working with two teams at the same company; one of which uses trunk-based development, and one which (for the moment) uses GitFlow.

This gives me a new perspective to see some of the differences between the two approaches. And one that has recently struck me:

GitFlow discourages refactoring.

I’ve been doing a lot of refactoring on the trunk-based codebase lately. Some minor. Some less minor. All related to improving the maintainability of the code. I might do 20 or even 30 small refactorings in a day. Each merged separately into the project.

But when it comes to refactoring the GitFlow codebase… Wow. It’s so much harder.

For one thing, doing 20 refactoring pull requests, just entails so much more overhead. It has to be approved. Then merged. Then merged again. Then merged again.

But what’s worse… because there are three long-lived branches in play, every refactoring tends to entangle all the other functional changes together, which makes it even harder to cherry-pick things from the development to advance to the sandbox or master branch.

So I’m left with two options:

1. Don’t do unnecessary refactoring.
2. Batch all my refactoring together, so the pain of advancing the changes through three branches happens less often.

Guess which one I usualy do? Yeah. I don’t do much refactoring at all.

Actually, there is a third option… The only one that actually makes any sense to me. And one we’ll begin working on next week:

3. Switch to trunk-based development.