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’ve been doing this for the past 10 years or so. When I joined my current company a few years ago, it was one of the first things I pushed for. It made cycle times go down drastically and value is being delivered to end users at a much higher rate now.

With enough tests and automation, there is almost no reason not do on the web. On embedded or mobile platforms this might be a bit more difficult, although not entirely impossible.

The use of feature toggles also greatly enhanced our trust in being able to turn a feature off again if it turned out to be faulty somehow. Although we usually opt for patching bugs, it gives the business as a whole more confidence.

Google operates on a trunk model, according to this:

dev.to/tbodt/comment/1j4e

Team of one here tends to work on master only for very small stuff.

There’s a branch for the next release which will get merged once everything’s done. Occasionally there are smaller branches that fork off of the release branch and get merged back.

Meanwhile master is, most of the time, an old copy of the new release branch so merging goes without issue. Unless there’s a problem in prod, then it gets fixed in master and backported to the feature branch.

I should use feature toggles more (usually #ifdef, sometimes if (config_Flag)), occasionally a big feature creeps in and i know management will change it at least 3 times and 2-3 new releases will come out in between…

At my last company, we used the scaled TBD. For personal projects I do the same. It’s honestly really nice. Not having to worry about merging issues between a dev branch and main branch was probably the biggest benefit. The code base also felt more accessible to the team. Cherry-picking a particular commit that a teammate worked on that’s been merged but I needed on my feature/bug branch was also painless.

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.

Team of three. We do the feature branches, pull requests and code reviews. With the right culture, it keeps devs informed about the various projects and gives a nice space to discuss about the practice.

EDIT: we do automated linting and formatting checks too. Keeps things coherent.

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.

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.

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.

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.

Worked with both, both worked fine.

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

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

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.

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

Life is too short to tolerate long-lived branches.

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?

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 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.

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

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.

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.

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.