How does 'Short-Lived Feature Branches' make trunk less prone to break than 'Committing Straight to the Trunk'?
joaompfe opened this issue · 2 comments
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 🙂 .)
No probs with the use of issues :)
I'll bite. Re "the committers guarantee to run the CI build before pushing". What do you mean by guarantee? When you say push, you mean from their (say) Thinkpad 's clone/checkout dir after a git-pull (from trunk) and to the canonical origin trunk on Githib/Gitlab etc.
Back before CruiseControl people used something like a rubber chicken as a checkin token. The pair (or person) wanting to check into the single branch (the trunk) would have to be holding the chicken physically. They would run the build (incl tests) then check in. Then another pair (or person) could take the chicken and do the same for their work to that moment. There was no chance with that rogor for someone else to beat them to a commit (a push today). There were accidental breakages despite all people running the build (incl tests) before commit/push. If we're doing checkin (commit/push) direct to trunk at anytime since the advent of CruiseControl (2001), we must be accepting of rare automated rollbacks of commits. Not becauee of lack of rigor, but because of accidents of timing. Google too checking to trunk after rigor to a few thousand devs before making a patch queue to pre-integrate what would land on the HEAD of trunk. That the patch queue (later called Mondrian) also allowed code review before that was great too.
Thanks for your quick answer!
When you say push, you mean from their (say) Thinkpad 's clone/checkout dir after a git-pull (from trunk) and to the canonical origin trunk on Githib/Gitlab etc.
Yes, exactly.
What do you mean by guarantee?
I mean that before pushing a commit, the programmer always runs the CI build locally and it is green. Sure, it is possible that while the CI is running locally the trunk's HEAD might get updated by someone else in a way that will make the CI break once the programmer pushes the commit (because the two commits don't work together). But AFAICT that problem can also happen in Short-Lived Feature Branches, where a programmer pushes a branch, the CI is run, and, before it gets (reviewed and) merged, someone else might update the trunk's HEAD in a way that will make the CI break.
This is why I cannot see how Short-Lived Feature Branches make the trunk more stable in comparison to Committing Straight to the Trunk while ensuring my two assumptions. But probably I am missing something.
Please let me know if something isn't clear.