Programming

Second diagram, yes absolutely.

Short lived (1-2 day) branches, and a strong CI systems to catch regressions.

Be warned, the strength in the CI lies in its capacity to detect when some functionality that previously worked doesn't work anymore. So, the flow must be green always, and it must evolve as the features evolve. Without good CI you're destined for failure.

Here there's main. You branch off. Do your work. Make a PR to main. Build passes and someone approves, merge to main. Production release is done by tagging main.

The branches are short lived because the units of work we select are small. You have like one pr for an endpoint. You don't wait until the entire feature with 20 endpoints is ready to merge.

Seems to work fine. I think this is different than trunk based development but honestly I'm not sure I understand trunk.

We do, for two 2-3 person projects, where no code reviews are done. This is mostly because (a) it's "just" a rewrite and (b) most new functionality is small and well-defined. For bigger features a local branch is checked out and then merged back later. Commits are always up-to-date, which makes it much easier to test integration of new featues.

I haven't worked on any teams where all members committed "every 24 hours", and there have always been some branches that live longer than we'd like (usually just unfinished work that got deprioritized but still kept as an eventual "todo"), but most teams I've worked on have indeed followed the basic pattern of only one long-lived branch, reviews and CI required prior to merge, and all feature-branches being short-lived.

I do, on a 900+ developer mono repo. Works like a charm.

We just have a CD that allows to deliver each project each micro service individually.