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.
Exactly my reaction as well. The only ‘benefit’ she lists that I can truly see is ‘greater visibility into the code everyone else is working on’ but frankly that seems like it could be a burden as well.
Sometimes you don’t need to know. If your team organizes it’s projects and assignments well, you very well may be able to work on your small piece and integrate it without really needing to know every little thing every other person is working on.
With frequent commits branches just seem like an easier way to resolve conflicts as well as speed up the ability for others to test and merge their changes while you can resolve issues with a build.
And I work at a company who switched to “trunk-based development” but because of bureaucracy, nothing can be merged early. Big feature branches still sit waiting for months, then need a big document describing the changes and their impact, some QA team to test the new feature branch build etc. The “release management” team simply renamed the develop branch to trunk and called it trunk-based development.
And the whole thing with running CI builds on branches not being “integrating” until merge time is so funny to me.
Like, does this person not know that you can merge master back into a feature branch, such that you are, in fact, integrating the feature branch up to date with master? And it’s done… Gaspwithout breaking the master build for everyone else in the mean time!?!
And the parts about pair programming and knowledge sharing are easy to fix, too. Just have regularly scheduled pairing sessions with the people who need to knowledge-share.
Trunk-based suggestions always comes across to me as “I don’t understand how to do feature branches/PR-based development”
TBD only says that you should have less branches than the other branching models. I quite like it and have used with git and merge requests. I may be misunderstanding something, but I only see this as a way to organize the branches, nothing more.
That’s not how I’ve ever understood folks to be describing TBD, but perhaps I’m misunderstanding it. To me it has always sounded like people should just commit to master and always commit tiny atomic commits.
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.
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.
Exactly my reaction as well. The only ‘benefit’ she lists that I can truly see is ‘greater visibility into the code everyone else is working on’ but frankly that seems like it could be a burden as well.
Sometimes you don’t need to know. If your team organizes it’s projects and assignments well, you very well may be able to work on your small piece and integrate it without really needing to know every little thing every other person is working on.
With frequent commits branches just seem like an easier way to resolve conflicts as well as speed up the ability for others to test and merge their changes while you can resolve issues with a build.
You can also typically see team mates branches in repos… Seems they are just missing SVN?
And I work at a company who switched to “trunk-based development” but because of bureaucracy, nothing can be merged early. Big feature branches still sit waiting for months, then need a big document describing the changes and their impact, some QA team to test the new feature branch build etc. The “release management” team simply renamed the develop branch to trunk and called it trunk-based development.
And the whole thing with running CI builds on branches not being “integrating” until merge time is so funny to me.
Like, does this person not know that you can merge
masterback into a feature branch, such that you are, in fact, integrating the feature branch up to date with master? And it’s done… Gasp without breaking the master build for everyone else in the mean time!?!And the parts about pair programming and knowledge sharing are easy to fix, too. Just have regularly scheduled pairing sessions with the people who need to knowledge-share.
Trunk-based suggestions always comes across to me as “I don’t understand how to do feature branches/PR-based development”
TBD only says that you should have less branches than the other branching models. I quite like it and have used with git and merge requests. I may be misunderstanding something, but I only see this as a way to organize the branches, nothing more.
deleted by creator
deleted by creator
That’s not how I’ve ever understood folks to be describing TBD, but perhaps I’m misunderstanding it. To me it has always sounded like people should just commit to master and always commit tiny atomic commits.