My problem with trunk based development is I feel like people treat it as the solution to a problem that is fundamentally a developer culture problem.
You need to commit small changes, frequently, which requires you to only change small sections of the code and make incremental changes, something which can be a difficult habit to get used to.
This is really the main benefit of trunk based development, and it’s something you can get with feature branches as well, you just have to make sure everyone on your team starts reducing scope of their features and merging in smaller and smaller features sets.
There’s nothing inherit in the trunk based development model that stops someone from sitting on changes for a month, never pulling, and then trying to pull and ending up with a bunch of conflicts anyways. So it really feels like “yeah use trunk based development” boils down to “integrate continuously” which can be done with a branching model.
Regarding section 1, won’t you still get the conflicts when pushing to remote (or pulling from it)?
I’m actually confused by the whole post.
In contrast, the branching model
TBD is a branching model which works fine with DVCS. I’ve used it successfully with git and it was better than the other “git/github flows.”
The point of TBD is to have well-defined branches for certain tasks or topics. Nothing is forced for how you achieve this. For example you won’t get conflicts if you have a rule to merge the master/develop/main branch, or squash or rebase your commits on your feature branch before your merge request is ready.
Also, I disagree with the person who says it’s a “developer culture problem.” IMHO it’s a branching model that should be respected in the same way we have rules for code formatting or using linters before a commit whether it’s a tool, a hook, or a check in the CI.
Overall I prefer TBD because it has fewer branches than the other methods.