[giancarlostoro]

I'm not really sure what the mental load is but having gone to Trunk felt like a mistake, I don't know if it was just designed wrong at the last place I worked at, but we have to do more than normal per release, and I'm not a fan of squashing commits, it means I can't just go back to a branch and merge the development branch back into it, I have to check out a brand new branch. I also preferred having "master / main" and "development" because if QA claims there's a bug introduced during the development phase, you can figure out if it's already in the main production branch or if it truly was introduced during development. Which is something you can't really do with "trunk based development" it's like all these people who praise it should just switch to SVN instead?

[andix]

I think you're mixing up a lot of things.

Trunk-based development also doesn't mean that you are not allowed to create branches.

And you can still check out an older version.

[giancarlostoro]

They deleted every branch on merge, and had us rebase for merges. Before trunk based development was introduced, everyone on the team understood what the flow was. Afterwards, whichever developer was picked to cut a release, took half a day to figure it out to make sure they didn't screw up.

I would have rather just used SVN and called it a day.

[afarviral]

Nothing is lost in git without great effort. Deleting a branch is simply removing the label from the history. Just take note of the hash of the latest commit on the "deleted" branch. It'll still be there and can be checked out in detached-head mode.

[purerandomness]

> They deleted every branch on merge

Wait, this doesn't sound like trunk-based development.

This sounds like a traditional branch-based workflow.

> to cut a release, took half a day to figure it out to make sure they didn't screw up.

Do you remember what was making the process complicated?

In trunk-based development, you ideally can tag a release wherever you're at. Your trunk is always stable and releasable. If it's not, you fix it and then release.

[GauntletWizard]

GitHub "deletes" branches on merge, but it doesn't truly delete them - rather, it removes the branch, that's deleted, but the commits comprising the "pull request" are saved and referenced from that pull, so they never go away. They're slightly harder to find in GitHub and may disappear from your local copy, though.

There's a lot of other moving parts to trunk-based, they can only be taught by experience. I've written the tutorial where I have people make mistakes, and then fix them, but the problem is that they make mistakes in making mistakes.

[giancarlostoro]

> Wait, this doesn't sound like trunk-based development.

I'm not sure, I just know my employer had a third party managing releases for a while, then the guy who pitched Trunk based dev left, and we were left with people trying to follow the breadcrumbs.

[andix]

Sounds like you can't agree on what you're doing and what your goals are.

[jfim]

You can rebase your development branch or cherry pick commits from master into it.

And if QA finds something, there's nothing preventing testing another release to figure out where the issue is. Git bisect is useful there too.

There are plenty of issues with git, but trunk development isn't really one of them.

[doobeewoo]

If you deploy your main branch on every commit, there is no "development phase". You should deploy more frequently and work on smaller changes. So when your QA (or a user, or a monitoring alert) finds a bug, you are pretty sure that the bug was introduced recently.