That's ridiculous, committing to the same branch doesn't scale beyond 1 dev.

Trunk-based means merge requests get merged into master instead of feature branches.

It's not ridiculous, we used "actual" trunk-based development on a single branch in teams between a dozen and a hundred team members (coders, artists, level designers and QA), since the mid-90's in CVS and SVN. It works very well but requires a different kind of discipline (if anybody breaks the build, this must be fixed immediately before anything else).

Git doesn't lend itself very well to this kind of development model though, because it's doesn't have a central repository like SVN.

Also see here: https://trunkbaseddevelopment.com/

The basic form of trunk-based doesn't use feature branches, the "scaled" version only uses short-lived feature branches. But I can assure you that the "scaled" version isn't needed for teams of up to around 100 contributors (with a centralized version control system like SVN that is).

Next logical step is for everybody to just ssh into common server and work there. But then you wouldn't dare to save your files before they are reasonably bug free.

Feature branches let you save intermediate work outside of your computer.

If you have trunk based development and your machine smokes, all unpushed work is lost.

People are looking for some philosophical advantages of one over the other. But in practice, it's just a trade-off of how much you save and where.

Just SSHing into a shared filesystem is really too simplistic. There's a lot of nuance between this extreme on one side, and feature branches on the other. Working exclusively with Git just doesn't make it obvious that there have been other working solutions before that don't rely so much on branching ;)

I think it really comes down to the differences between a distributed versioning system like Git, and a centralized versioning system like SVN. A lot of the "branching ceremony" that evolved around Git is about managing the different timelines that evolve because every dev has its own local repository with its own history which then needs to be synced with a remote repository, and this entire problem area simply doesn't exist if there's only a single shared repository.

In SVN there are no "merge commits" polluting the history when working on a single branch. If you update (in git lingo: pull), there are no "merges" or "rebases" happening, instead you get conflicts that you need to resolve locally. Next time you "commit" (in git lingo: push) those resolved conflicts are uploaded to the central repository as if they were regular changes (e.g. no "merge commits").

Somehow this central-repository-model of SVN still is much more logical to me. The distributed model of Git doesn't make a lot of sense unless you're a Linux dev with your own 'fork' sending patches to upstream from time to time via email (e.g. despite git's decentralized nature, Github or Gitlab are also just trying to emulate a simple central-repository-model).

Aso:

> If you have trunk based development and your machine smokes

That's why you commit to trunk just as often as you would push to a feature branch. You just have to organize your work in a way that frequent commits don't break the build (e.g. by putting your work behind a runtime feature flag), the upside is that you never get into a state where you need to deal with complex merges, because your work never differs from the shared project state by more than a few hours.

I worked with SVN and it was just horrible. Merges were horrible. Even resolving conflicts on updates was arduous, error prone and hard. If two people accidentally worked on the same file, both were screwed. Git was the first thing that made merges feasible. (Not really the first I think, my initial bet was on mercurial, but git was the one that stuck).

Runtime feature flag sounds absolutely repulsive. And to avoid complex merges you can just rebase your feature branch onto current trunk often and either avoid working on two large tasks affecting same area simulatnously or merge or rebase one on the current state of the other when the other is in stable enough state.

You probably worked with SVN before 'merge tracking' was implemented, after that merges were really not that different than in Git, especially with a UI frontend like TortoiseSVN. Both Git and SVN absolutely break down when it comes to merging binary data though, and in game projects binary data is the vast majory of all project data (in our projects about 95% binary vs 5% text data), and this is actually the main reason to avoid branching at all cost (or rather: branching is fine, merging of binary data that has diverged between branches is the problem, and Git doesn't solve any problems in that area over traditional version control systems).

But still, branches are simply not as important in a centralized version control system where everybody works on the same shared repository state.

Runtime feature flags also make a lot of sense outside the version control worflow. If you have a "live product" you often want to enable or disable features after a new version went live, sometimes only for a group of users.

> You probably worked with SVN before 'merge tracking' was implemented

Yeah, most likely. Since SVN is not dead yet, that must be have been the case because I don't see how any modern dev could suffer with SVN I suffered with.

I see how having binary data checked out into git and merging in any manner other than "use A" or "use B" might be a nightmare and how never branching might be the best (or even the only) way to even be able to use versioning at all.

I remember that when at some point I started using sqlite in my projects I wanted to have another database format I could check into the repo that would use multiline text representation for the data and things that must be binary like indexes would be just generated on deploy.

I can't imagine needing to have in my source tree some opaque binary formats that might be altered partially. I think I'd just kept those outside and use meatware process to manage change in them. Or have some migrations system where updates to binary files might be described textually and checked into the source tree.

Merges still brake with false conflicts in SVN with "merge tracking" when directories are deleted or renamed.

Merge requests into a feature branch sounds like an over-engineered process, but maybe that works for large teams?

A new feature might require new/changed backend APIs, iOS and Android and WFE changes that might all be handled by different devs. Having them work from a shared feature branch can be a practical strategy, if there's a desire to keep things out of master until they're fully ready.