Programming

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've used the "scaled" approach for a whilen and we make tags to release. Every time we have a long-lived branch that isn't main/master something gets fucked up or we spend an extra few days just to reconcile the conflicts. Luckily we're service based so supporting multiple versions of a product is very rare.

We don't have release branches, the commit is just tagged as being currently deployed in production.

People merge their feature branches to master during working hours (by merging CI validated PRs) and release when they get a chance. Normally do about 10-20 releases per day.

This actually seems like git flow, but easier while achieving the same objectives.

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.

We have hundred of individual repos and use git flow: short lived feature branches but also long lived develop, master and support branches (for LTS releases).

I guess we do scaled trunk development, if you want to call it that. We do allow direct commits, for trivial or safe stuff where reviews would be more noise and hindrance than value. (Code formatting etc.)

We only have one current release version though. (And at times a current test version that deviates from it.)

If there's a need to create a patch release for a tagged version when the trunk proceeded forward with something that shall not be included, I create only a temporary branch from the earlier tagged commit to tag (=create) that patch release.

What are the release branches supposed to be in your graphs? It says developers don't commit. Then who does?

Scaled trunk based all year long, every year, every team.

Life is too short to tolerate long-lived branches.

Scaled absolutely. Works really well. We have a pr ci pipeline. And cd set up on the trunk. Everything is PRed before being merged to the trunk.

Yes. We use SVN. I hate it. I'm trying to build a case to switch to git. We're a small team, but a growing team

Only for repos where there are no code reviews or releases. E.g small single developer utilities, configuration repos, etc.

Worked with both, both worked fine.

Scaled trunk based development for sure, we're a two man team, I do backend the other guy does frontend, but still we use that.

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.

I’ve been a fan of git-flow for a long time. It makes the master consistently stable and production ready, gives mechanisms for hotfixing, patching, releasing, tagging, and regular feature dev with a running develop branch. This tends to be more stable than Wild West commits into dev direct, since you work on a feature in isolation, and then merge the feature in when it’s ready, and keeps prod in its own lane so there’s no risk of a feature accidentally nuking something.

Not saying anything about good or bad, but trunk-based development doesn't work when the business requires you to have multiple releases under development concurrently.