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
The 15yo “source” for the sloppy plagiarism: https://nvie.com/posts/a-successful-git-branching-model/
OP responded to the great Morge: https://nvie.com/posts/15-years-later/
You gotto love how the AI took the axis on the left, was confused enough from its tail that it thought it must be pointing in the opposite direction to development flow and then went “welp if it is going in the other direction, the label “time” must be a typo. Ima make it Tim the time traveller instead”. Ofcourse none of it happened like this, but I would like to imagine that it did.
holy fuck, it’s basically the time I followed a tutorial for generating “a witch” for AI art, and ended up with a horribly mangled MTG card
Wow, it stole it badly enough that it might not count as copyright infringement in court, but it also stole it badly enough that it isn’t useful at all.
It’s still not a bad system if you have to support and provide bugfixes for multiple versions of software. However, if you only support the latest version and only create bug fixes and features based on the latest release or main branch, then git-flow is way overkill.
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.
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.
I dream of getting back to TBD.
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)