Trunk-Based Development

This workflow, like all others, is just a formalization of some reality. The reality is that many organizations and teams run on nothing but trunk - and it more-or-less works on them. Some teams work by building blocks separately and then joining them together; other prefer to hammer away on a problem all together. Both approaches work. What worries me are emotional claims that the other approach is fundamentally flawed, or that some git workflow is The One True Way…

I work at a place that has a few very large code bases, we use trunk-based. I will never go back, "what is your git workflow?" Is a question on my list of things to ask potential employers now and the only good answer is "trunk". So much mental load is wasted on these other strategies.

I've rarely seen the first description of it where people actually commit directly to main. Except in very early stage projects. But it does always feel the fastest if you only review code "on-demand" in PRs/MRs instead of enforcing it for every change. I think in a team with good ownership, enforcing formal reviews slows down a lot. But of course in a larger code base where no single engineer can understand all the effects a change might have, having…