The article linked is a site all about trunked based development.

>So what is it exactly? Linear history?

The essence is that changes developers make are included into the trunk (main / master branch) as fast as possible. Developers shouldn't be branching off and spending a bunch of time making commits without them being added to to the main branch.

You can run CI/CD on the commits developers want to get rebased onto the trunk.

Point two: Alternatives to source control branches are dark launches, branch by abstraction and feature flags.

Point three: The best results that I have had on developing systems were doing exactly that. You need more discipline (like make sure that you run test and linters locally), but my experience is that makes the whole process easier.

CI is continuous integration, there is nothing continuous to coding on your branch and merging after a few days.

> You need more discipline (like make sure that you run test and linters locally)

That sounds error prone. Wouldn't it make more sense to have an automated system to run tests and linters for you...?

> but my experience is that makes the whole process easier.

Sounds like you would just have people breaking `master` constantly to me. And how do you do code review? Or don't you?

> there is nothing continuous to coding on your branch and merging after a few days.

Yeah I guess the meaning has changed a little (or maybe standards have changed). These days CI basically means automatically testing every commit.

Code reviews happens when you update trunk. You eye through the latest changes and if you see something particularly gregarious there you either fix it yourself or you tell them about it. People of course shouldn't commit stuff that breaks the build, but that is irrespective of whether you are using feature branches or not.

All these things sound highly optimistic. You're just hoping that people will run all the tests before pushing (what if CI time is over an hour?). You're hoping that people retrospectively review changes (what if the project is very big?).

I'm only seeing disadvantages compared to traditional MR/PR/diffs.

If they don't CI will fail and not even show that as code to review so it's not exactly an issue. And if they push to master it can always be reverted and the clown shamed. Works well enough

> You're just hoping

...yes, hoping that I'm not working with idiots and change the job if I would be.

It's different for OSS or any project with external contributor but you need to require some minimal level of competence

> If they don't CI will fail

Yes, CI failing is a big issue! It means you can't bisect, and you show everyone else down while the big gets fixed.

> hoping that I'm not working with idiots

Ah you're one of those "only idiots make mistakes" types. Ok never mind; I hope you can learn that everyone makes mistakes - including you - one day, but I won't try to convince you now.

(You have successfully convinced me that trunk based development is a terrible idea though; at least for anything more than tiny teams working on small projects.)

Throwing some bad commit once a month is not a big deal and not "idiocy" I'm talking about. CI ain't gonna deploy it anyway. At absolute worst you'd have to "git bisect skip" it during bug hunt that one time in two years you get unlucky to hit it.

I'm talking about people that constantly do same stupid stuff or go around system put in place coz they think they are smarter and want to shave few seconds off

We do a bunch of checks in pre-commit stuff but nothing delaying it much, and trust devs will commit working tested code. So far that social contract works just fine

And yes, you can put far less baby bumpers around stuff and go faster if your co-workers are not babies that need every sharp object hidden from them.

> Sounds like you would just have people breaking `master` constantly to me. And how do you do code review? Or don't you?

Pair and Ensemble programming