[ludocode]

Trunk worked fine for Subversion since it kind of sucked at branching. You generally had to have a reference branch where everything else was understood to be a copy of it.

Modern systems like git don't really work this way. I don't think trunk is properly descriptive anymore because it isn't necessarily the root of all branches. In a GitFlow branching model, commits can move back and forth on feature, bugfix and release branches without ever being merged to develop. On top of that you have branches like gh-pages which should have no shared history at all with other branches.

In keeping with GitFlow, the main development branch on many of my projects is called "develop". I like the name: this is where development happens, where new features are first merged. Unlike "master" or "main" it doesn't imply that it's stable or deployable, and unlike "trunk" it doesn't imply that it's special or that it's the root of all other branches.

[darkwater]

> Modern systems like git don't really work this way. I don't think trunk is properly descriptive anymore because it isn't necessarily the root of all branches. In a GitFlow branching model, commits can move back and forth on feature, bugfix and release branches without ever being merged to develop. On top of that you have branches like gh-pages which should have no shared history at all with other branches.

This criticism apply to every other branch naming, especially "master" (it's not a master copy of anything, then). Maybe "main" would be the best one since it highlights the most important branch of that git tree.

[samatman]

Sure, and this is one of the nice things about git, that it supports a number of flexible workflows.

My repos are in fact trunk and branch shaped: the trunk branch is always the first commit, and I tend to just have feature branches. That won't last forever, I'll need to start having release branches and the like, but 'trunk as root' with the first commit is going to be a constant.

So 'develop' is a fine choice. I worked at a company which had a 'master' branch but really only used it for releases. It wasn't a continuous deployment model, so everything would land on 'develop', turn into a candidate branch near release time, and then land once on master when it was blessed for release.

So master was just a series of squashed deltas between point releases, which kind of matches the semantics of 'master' if you squint: like it was the gold master from which release copies (including one client who took delivery by CD-R!) was pressed.

[Cthulhu_]

Most of the Git projects I've worked with followed the "trunk" model of there being one core branch; in theory, you can use git in other ways but in practice that's the main one. That said, trunk works, but so does main, production, or even development depending on whether you want to communicate that the mainline branch is considered stable or unstable.