> This seems to be advocating the second workflow, i.e. pushing on a short lived branch then merging back in

No, in trunk-based development, you push to the trunk, aka master.

The difference is perhaps not that big; with TBD, you have a branch, but only on your machine, which you merge to master before pushing, whereas with the second workflow, you push your master, then merge somehow.

> their intermediate setup seems impractical technically for most setups - how do you run standard tests without committing your code, unless you do everything locally?

I don't understand this. Of course you can and should run all tests locally.

> No, in trunk-based development, you push to the trunk, aka master.

If you follow the ops link there are multiple diagrams where that is not the case.

You answered the question. You run as many tests as you can locally. Sometimes you can't, and the build goes red and you fix it with another commit.

Any workflow that involves breaking master for everyone seems broken at some level.

Not saying I have a better solution off the top of my head, but "just fix it with another commit" is a big red flag IME.

Even if you really wanted to have it be trunk-only, I don't know why you wouldn't make everyone push to a feature branch, then have automation for running tests and merging after they pass. Plus, where's the code review in this process? Even if your team is all amazing developers somehow, it's insecure to have a standard process where developers are pushing unreviewed code directly to production.

Fundamentally this all seems like a misreading of trunk-based development, though. The whole idea was to get away from old Subversion-style branching, where there would be long-lived branches running for sometimes several month. If you were a company that moved from svn -> git, trunk-based development was a way of communicating that branches were cheap and disposable, and merging was quick and easy.

Master isn't broken for everybody though? Its just broken for those projects whose tests are broken, everybody else can still work as normal.

So unless you have a ton of dependencies you wont notice much breakages from other teams.

A broken build is meant to be everybody helps fix it situation.

I'm questioning the logic of having a workflow with a not-uncommon case of "this is on fire now everyone stop what they're doing and help me fix it" which is exactly what you'd have here.

Tests breaking should be rare. And trunk based development requires the team working closely together. So working together isn't a adrupt thing.

One of the premises is that the minimum level of competence of the team should be above average, which is not feasible everywhere.

And

"The short-lived feature branch should only last a day or two and never diverge from the trunk enough so that a merge back is problematic. After the seal of approval from code reviewers and CI daemons, it should be merged back into the trunk. It should be deleted, as proof of convergence. The developer in question may then go ahead and make the next short-lived feature branch for the next story/task they’re doing" https://trunkbaseddevelopment.com/youre-doing-it-wrong/#dura...

This is a very git-centric view. There are other source code management systems.