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.
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.
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.
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.
> 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.
Trunk-based development also doesn't mean that you are not allowed to create branches.
And you can still check out an older version.