this post was submitted on 17 Feb 2026
263 points (98.9% liked)

Programmer Humor

29836 readers
732 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

founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] Gyroplast@pawb.social 60 points 22 hours ago (5 children)
[–] credo@lemmy.world 19 points 14 hours ago
[–] Ephera@lemmy.ml 7 points 14 hours ago

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.

[–] Skullgrid@lemmy.world 14 points 22 hours ago

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

[–] pizza_the_hutt@sh.itjust.works 10 points 22 hours ago (1 children)

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.

[–] lmmarsano@group.lt 10 points 21 hours ago (1 children)

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.

[–] thesmokingman@programming.dev 3 points 17 hours ago (2 children)

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.

[–] draycs@lemmy.world 3 points 11 hours ago

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)

[–] chunkystyles@sopuli.xyz 4 points 13 hours ago

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.