This was from official Microslop documentation https://web.archive.org/web/20260216165612/https://learn.microsoft.com/en-us/training/modules/introduction-to-github/3-components-of-github-flow
This was from official Microslop documentation https://web.archive.org/web/20260216165612/https://learn.microsoft.com/en-us/training/modules/introduction-to-github/3-components-of-github-flow
It’s an atrocious, pointlessly complicated system resulting in convoluted project histories prone to confusion. Trunk-based development with sensible tags of releases & hotfixes achieves the same thing without the junk complexity. Git flow isn’t overkill, it’s just ill-conceived.
This is a joke, right? OneFlow isn’t trunk-based development and is actually gitflow with different steps. I have yet to see any org actually use trunk-based development mostly because I’ve not seen cherry-picking from the trunk adopted at any large scale.
What is large scale to you? We have 100-200 developers doing something fairly close to trunk based development. Including cherry picking from trunk when possible (not always practical for sufficiently old release branches)
I pushed my team to use trunk based development. We did cherry-picks from trunk to release branches for a couple years with no issues. Since then, I’ve written a GitHub action that automates the cherry-picks based on tickets in the commit messages.
But even before the automation, it drastically improved our dev processes.
We weren’t on Git Flow exactly, but it was a bastardized version of it.
Having used TBD successfully for like 5-6 years now. I can’t imagine using Git Flow.