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 post was submitted on 17 Feb 2026
265 points (97.8% liked)
Programmer Humor
29853 readers
79 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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/
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.
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
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)