Long-lived branches discourage refactoringEvery refactoring tends to entangle all the other functional changes together, which makes it even harder to advance changes to the production branch.
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
So I’m left with two options:
- Don’t do unnecessary refactoring.
- 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:
Who cares if we use GitFlow?
GitFlow vs Trunk-Based Development is like Coke vs. Pepsi, right? Not really.
Implementing Continuous Delivery in Reverse - ATVIE22
If you heard about Continuous Delivery you might find it sounds great, but you are not ready for it because [insert excuse here].