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