How does 'Short-Lived Feature Branches' make trunk less prone to break than 'Committing Straight to the Trunk'?

[joaompfe]

In Short-Lived Feature Branches says

What you get (if you’ve attached build automation too), is a trunk or main that’s never broken (or 1/1000th as likely to).

giving the impression that is harder to keep the trunk unbroken in a Committing Straight to the Trunk style (which is described in the preceding section).

My question is whether my interpretation is correct — the author does believe that keeping the trunk unbroken is easier in a Short-Lived Feature Branches style than in Committing Straight to the Trunk.

And if that's the case, I would like why. Assuming that 1) your CI build is environment-independent (such that you get always the same results whether running locally or on the CI server) and 2) the committers guarantee to run the CI build before pushing, how does Short-Lived Feature Branches bring more certainty that trunk will not break?

In my understanding, the only difference between the two styles is when the (human) code review might happen (which in Short-Lived Feature Branches is always guaranteed to happen before integrating), but that does not influence the result of the CI build.

(I hope this is a proper place for questions. If not, sorry in advance. And many thanks for your website, it has been very useful to me :slightly_smiling_face: .)