3 ms·
> everyone makes small PRs to it I don't think that's the trunk based development that they're advocating for. I believe the version they're advocating for is
by chippiewill 3y ago
> everyone makes small PRs to it
I don't think that's the trunk based development that they're advocating for. I believe the version they're advocating for is where all developers commit and push changes directly to the main branch.
- goodoldneon 3y agoHow would code review work if everyone is committing and pushing? The article must mean tiny, short-lived branches
- kdmccormick 3y ago"Pair programming", maybe? Anyway, agreed. Particularly, I wonder how any significant refactoring is approached.
- jdlshore 3y agoRefactoring is easier with short-lived (minutes to a few hours) branches, because refactoring causes branches to diverge over time. Significant refactoring, done correctly, is a series of small refactorings, and they can be integrated every 30-60 min to minimize impact of changes.
- claytongulick 3y agoWith trunk based, code review happens as a sort of forcing function every time you do a pull and merge it in. You see what everyone has done and how it affects you before you can push. (I'm not advocating for this, but I've worked in this style and it has pros and cons).
- kdmccormick 3y agoYeah, you're right. I just think that what the article argues for is a just a worse version of trunk-oriented git usage. Every benefit the article names is available via git, but git also gets me a place to share and automatically test my changes (which might be a simple but risky refactoring) without literally editing the trunk. If there is a benefit to true trunk-based development over just trunk-oriented DVCSs usage, the article did not describe it.