4 ms·

I'd be interested to hear from anyone with substantial experience of trunk-based development who prefers a merge workflow, and can articulate why. Comments on T

by twic 2y ago

I'd be interested to hear from anyone with substantial experience of trunk-based development who prefers a merge workflow, and can articulate why. Comments on TBD posts are usually either TBD enthusiasts, or people who have never used TBD and think it sounds stupid.

tcoff91 2y ago
I have worked with trunk based development aka everyone just pushing change lists to perforce. I much prefer people making pull requests because I can make sure people fix things in code review before it gets merged to master. I do absolutely hate however when someone works for 3 months on a mega PR and drops a +8000 -5000 on my head. Ultimately both systems can work and both can suck.
- gregmac 2y ago
  I echo this. No pull requests is awful. The only time it's worked well for me is with 2 or 3 people sitting next to each other, with the same mindset and coding style. Every other time I've seen or worked with teams doing it, their codrle is, well, bad. It "works" but it is full of stuff half-done, "we'll clean that up later" - except it's been there for 3 years. And I'm looking at it because I'vr narrowed down a production problem I was called in to debug, that turns out to be crappy error handling with terrible logging that mislead everyone on what was going on. A proper PR should have flagged that and asked for something slightly better than logging "something went wrong" in an try..catch statement that spans many hundreds of lines of code. Small, focused PRs are good. Easy to review, code gets merged fast, conflicts are minimized. Massive PRs are bad, they are hard to review (problems get missed) and slow to get approved. If they get reverted because of a problem it's a mess to fix. PRs that do multiple separate things (fix two unrelated bugs, add a feature, and reformat spacing in 30 files) are impossible. If PRs are small and focused, the duration of time the branch is open, number of commits and the actual branching model does not matter. Long lived branches are a pain to the author (they're who has to merge Main and resolve conflicts), but that's their choice.
- inetknght 2y ago
  > I do absolutely hate however when someone works for 3 months on a mega PR and drops a +8000 -5000 on my head. Trunk based workflow doesn't prevent that. Moreover, heavy refactoring of code often ends up doing the same thing but much quicker.
JTyQZSnP3cQGa8B 2y ago
TBD has merge requests. It lacks all the weird branches like hotfixes and goes back to a simpler set of branches. But MRs are still there. The author of the post is confused or is trolling on purpose of selling his tool. That is very dishonest.

by twic 2y ago

tcoff91 2y ago

I have worked with trunk based development aka everyone just pushing change lists to perforce. I much prefer people making pull requests because I can make sure people fix things in code review before it gets merged to master. I do absolutely hate however when someone works for 3 months on a mega PR and drops a +8000 -5000 on my head. Ultimately both systems can work and both can suck.

gregmac 2y ago
I echo this. No pull requests is awful. The only time it's worked well for me is with 2 or 3 people sitting next to each other, with the same mindset and coding style. Every other time I've seen or worked with teams doing it, their codrle is, well, bad. It "works" but it is full of stuff half-done, "we'll clean that up later" - except it's been there for 3 years. And I'm looking at it because I'vr narrowed down a production problem I was called in to debug, that turns out to be crappy error handling with terrible logging that mislead everyone on what was going on. A proper PR should have flagged that and asked for something slightly better than logging "something went wrong" in an try..catch statement that spans many hundreds of lines of code. Small, focused PRs are good. Easy to review, code gets merged fast, conflicts are minimized. Massive PRs are bad, they are hard to review (problems get missed) and slow to get approved. If they get reverted because of a problem it's a mess to fix. PRs that do multiple separate things (fix two unrelated bugs, add a feature, and reformat spacing in 30 files) are impossible. If PRs are small and focused, the duration of time the branch is open, number of commits and the actual branching model does not matter. Long lived branches are a pain to the author (they're who has to merge Main and resolve conflicts), but that's their choice.
inetknght 2y ago
> I do absolutely hate however when someone works for 3 months on a mega PR and drops a +8000 -5000 on my head. Trunk based workflow doesn't prevent that. Moreover, heavy refactoring of code often ends up doing the same thing but much quicker.

JTyQZSnP3cQGa8B 2y ago

TBD has merge requests. It lacks all the weird branches like hotfixes and goes back to a simpler set of branches. But MRs are still there. The author of the post is confused or is trolling on purpose of selling his tool. That is very dishonest.