3 ms·
> 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
by purerandomness 3y ago
> 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.
- giancarlostoro 3y ago> 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.
- GauntletWizard 3y agoGitHub "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.