For me, history documents changes and intention. Trunk based development seems inherently incompatible to that.
Many small commits intertwining different concerns makes it practically impossible to grasp changes by concerns or change sets. Once an issue inevitably occurs you may be able to work on the current state, but you can’t check what was changed together and why. If it’s not obvious from the code base you won’t be able to quickly assess the context.
The idea or thesis that many changes would lead to more stability (always deployable) is baffling to me. Changes are what introduces new issues. Mixing and intertwining concerns and people unaware of other changes in close time proximity increases risk.
More commits also don’t mean CI is more stable. A merge request as a gate to CI success is what does. A failed build on trunk already failed and blocks others.
While I develop a solution I specifically don’t want it on main. It’s a messy process, that may be partially reverted. Once I found my approach I clean up / define history and explain the approach and changes.
I want to commit the messy process too, for reference of my changes and approaches, and to have stuff I split off and integrate later. None of that belongs into main before I’m confident in the approach and changes. Because it’s specifically not stable and should not be deployed.
For me, history documents changes and intention. Trunk based development seems inherently incompatible to that.
Many small commits intertwining different concerns makes it practically impossible to grasp changes by concerns or change sets. Once an issue inevitably occurs you may be able to work on the current state, but you can’t check what was changed together and why. If it’s not obvious from the code base you won’t be able to quickly assess the context.
The idea or thesis that many changes would lead to more stability (always deployable) is baffling to me. Changes are what introduces new issues. Mixing and intertwining concerns and people unaware of other changes in close time proximity increases risk.
More commits also don’t mean CI is more stable. A merge request as a gate to CI success is what does. A failed build on trunk already failed and blocks others.
While I develop a solution I specifically don’t want it on main. It’s a messy process, that may be partially reverted. Once I found my approach I clean up / define history and explain the approach and changes.
I want to commit the messy process too, for reference of my changes and approaches, and to have stuff I split off and integrate later. None of that belongs into main before I’m confident in the approach and changes. Because it’s specifically not stable and should not be deployed.