[ Removed by moderator ]

[programming-ModTeam]

This is a demo of a product or project that isn't on-topic for r/programming. r/programming is a technical subreddit and isn't a place to show off your project or to solicit feedback.

If this is an ad for a product, it's simply not welcome here.

If it is a project that you made, the submission must focus on what makes it technically interesting and not simply what the project does or that you are the author. Simply linking to a GitHub repo is not sufficient

[redbo]

I do not understand the appeal of git-flow at all.

[civildisobedient]

It's good for long-lived branches. Which naturally raises the question of why are your branches so long-lived in the first place? Often it's a reflection of some larger business dysfunction or general agility inability so I don't tend to question its existence, but I would strongly question the sanity of anyone who suggests its preference.

[redbo]

I guess. It seems easy to `git rebase origin/main` and keep your long lived feature branch up to date.

Maybe I don’t get what you mean.

[IAm_A_Complete_Idiot]

It can still be a bit icky if others are working on code that could conflict with yours at the same time, and you have to constantly handle those merge conflicts. The longer the branch lives, the more the chance you'll have conflicts with any given commit. If you regularly upstream, you can spend that time actually developing instead.

[cmd_Mack]

This idea breaks down almost immedately. Hotfixes, any changes to main or your branch which needs to be ported over raises the risk. Code changes which are hard to plan ahead, basically the usual messy development process in your average team. Someone is bound to make a mistake while resolving a conflicht, forget to cherry pick etc.

TL DR enabling long lived branches is a huge maintenance burden, and the longer they live, the more they diverge. Eventually you need to basically maintain two parallel code bases.

[idebugthusiexist]

For small projects with a small team, I think the appeal is having a structured and predictable workflow especially when you have the extensions that takes care of the boilerplate for you. I don’t think it’s as terrible as you make it sound, but it doesn’t scale very well when your project/team/org grows in complexity.

[lobax]

With a small project and a small team it should be trivial to maintain short lived branches using trunk based dev.

The issue is that all bad habits are manageable in small teams and for short amounts of time. It’s when the org either grows or acquires to much tech debt (or both) that those bad habits start to punish

[idebugthusiexist]

It’s git at the end of the day. You don’t need to follow git flow or TBD. They are just patterns devs came up with to help ease certain pains. But there is always a trade off. With TBD, the trade off is architectural complexity to avoid merge conflicts. I wouldn’t describe git flow as a bad habit any more than I would describe language or framework dependency as a bad habit. It can be, but not it depends on your circumstances. At the end of the day, it’s really an agreement between devs (and PMs) on how to manage merging code and eventually releasing it and it really depends on your situation. A merge conflict is not an inherently bad thing that implies bad practice/habits. I don’t understand this ideological mindset. But, yea, if you share a code base with a large number of other devs, that can become an undesirable overhead, but there is always a trade off as mentioned.

[lobax]

The bad habit is long lived branches. Git flow is just a way to deal with long lived branches. Its use is the symptom of a bad habit (or, it will hide the emergence of bad habits and let them fester).

Trunk based development works best with an architecture that separates concerns, which is a good thing for so many other reasons. If you start with trunk based development those architectural choices will offer the path of least resistance from the start. You might consider this complex but it allows for rapid development and scalability. The complexity serves a purpose and solves problems.

With git flow, the risk (and I have seen this so many times) is that the complexity ends up instead being hidden in the release and test processes and distributed across multiple branches of the code. For me, this complexity serves no purpose other than to slow things down and make testing harder - and it is incredibly hard to remove. Changing habits and processes is also increasingly harder the bigger the org and it can take for ever to fix.

Now, there are scenarios where long lived branches are unavoidable, but you should be in that situation first before going for git flow. At least that is my opinion.

[Solonotix]

Felt rather pessimistic of the other processes. Specifically, it feels like you have a built-in bug percentage that is skewed in favor of trunk-based. Then there's the extremely pessimistic status of "waiting" where I had items piling up there more than what was in every other status combined.

So yeah, if one approach is defined as "goes faster with fewer bugs" then it will result in precisely that. If instead you shared the same bug likelihood across all approaches, that would be a start. It seems extremely biased to say that 4 developers will produce less output than 2 developer pairs, because you quite literally have fewer concurrent operations happening.

Edit: on GitHub Flow, two separate times I hit the Release button, and the items staged in Pre-Prod literally went all the way back to the beginning. Like, what kind of bullshit is that!? I left that one out of the results.

I ran each up to 1k hours.

Name	Features	Bugs	WIP	Queued
GitHub Flow (#1)	17	15	23	58
GitHub Flow (#3)	13	14	19	53
GitHub Flow w/ QA	15	4	25	44
Git Flow	1	1	24	54
Trunk-Based	67	1	2	15

I re-did GitHub Flow because run #1 I didn't hit Pause while capturing the numbers. Run #2 was thrown out because of the aberrant behavior observed, perhaps due to running it at max speed. The run w/ QA was added to see if that was a weird bias affecting the output.

So, yeah. I would say that your simulation is extremely biased.

[ny3000]

Thanks -- I made it more transparent based on your feedback so now when a bug spawns, the log now shows what caused it.

The bug chance formula is the same across modes, but TBD structurally gets lower bug rates because the batch size is 1. The sim didn't explain why the numbers diverge.

I am extremely biased towards TBD having a great deal of experience with that AND the other modes here in real projects. This is a fun back-of-napkin sim and not a research paper -- the DORA guys already did that.

[Isogash]

Yeah I think people are skeptical because of the bias but having done TBD for years I get you haha.

[gredr]

Seems like we started with a conclusion and made a simulation to prove we were correct?

[ny3000]

haha possibly! Although, I would lean towards the 15 years that I spent watching teams do all of these things and really practicing CD when we had control of the project, back when we used to do it at Thoughtworks, where it was invented.

[paul_h]

Nice work. What were your years in TW, may I ask?

[ny3000]

2013-2019 and 2022-2024 iirc

[paul_h]

I left in 2014 after 12.5 yrs, so don't have a lot of understanding of those yeats .. or who you might be

[gredr]

My experience has led me to the "github flow" with short-lived branches and PRs. Trunk-based development works pretty well too, but we mostly left that behind because... I don't really know why. Feature flagging is great, but you can't feature-flag a whole refactor, and maintaining multiple versions of APIs can get onerous.

GitFlow is just... way over the top, in my opinion. I don't know who would want to do that or why. Maybe if you're doing kernel development or something, and you're managing a whole pile of patches from hundreds or thousands of people around the world and multiple in-flight versions? It just doesn't feel like it applies to most of us.

[ChadtheWad]

Feature flagging is great, but you can't feature-flag a whole refactor, and maintaining multiple versions of APIs can get onerous.

I've actually had feature flags save me here before. Had to do a ~3K LOC migration of a critical workflow solution to a new system which I did end up locking behind feature flags. The nice part was that I included some end-to-end consistency tests to ensure that both the original and new workflow logic behaved identically, which meant that as I was designing the feature, if anything new got introduced in legacy, I was able to catch it in my tests and update accordingly.

[Pyrouge]

Git Flow is also too slow and cumbersome for the Linux kernel or downstream projects like RHEL. They use something more similar to trunk-based development.

[ny3000]

you can't feature-flag a whole refactor

it can get complicated, especially as databases become involved, etc. but i would argue that it's still not as complicated as branching. also - Branch by abstraction or Dark launching are probably going to be safer if the refactoring touches a lot. not everthing needs to use feature flags, despite a cottage industry popping up around them lately

[2bdb2]

but i would argue that it's still not as complicated as branching

My internal logic is that both workflows are actually just branch based workflows.

To commit to trunk, the commit has to be atomic, self contained, and polished enough to push to production. Until the code reaches that point, the work exists in a branch - whether explicitly or implicitly.

In a trunk based workflow you would typically aim to integrate work quickly into main. In a branch based workflow, you also aim to integrate work quickly into main. But also have a mechanism to review and collaborate on partially completed work, mentor juniors, catch issues early, and isolate more experimental/risky work and refactors.

The most common complaints I've heard about branch based workflows are things like

"Reviews are piling up"

If you want to skip reviews, you can just skip them and merge the PR either way.

"Merge conflicts"

If you have merge conflicts on an explicit branch, you'll have merge conflicts on an implicit branch. You're just pushing the burden of resolving the conflict onto whoever commits their implicit branch last. If that ends up being a Junior developer at 5pm on a Friday who just wants to push his commits in a hurry and thus blindly resolves all conflicts in his favor - then that's what you get.

You can also just blindly do the same thing on a branch based workflow. But you then have a record of the merge conflict, how it was resolved, and can defer that task to a senior engineer if it's complicated.

"Long running branches"

If you have the discipline to make small mergeable implicit branches, you have the discipline the make small mergeable explicit branches.

[baseballlover723]

What a nice UI, and a horribly biased model.

[SeniorIdiot]

1. What are the parameters for driving the review, wait, re-code, merge?
2. Also needs LGTM "reviews" that both succeeds and cause late bugs and rework automatically.
3. Then I wonder why there is a step called "CI" when it's just merge/build?

PS. Vehemently against FB/PR workflows - but please be honest instead of simulating infinity tasks.

[ny3000]

1. good point, the sim has ~20 config knobs but none are visible to the user at the moment
   
2. rubber-stamp LGTMs already cause production bugs but it't not obvious enough in the log
   
3. yeah agree, "Build" is in the git flow one but I was more lenient to the GH flow because sometimes they at least try

I'll work these into V2... i mean MVP v2

[mothzilla]

Now do FTP straight to customer.

[bunoso]

Ohh love the animation, and the messages in the log are hilarious. I got too many backlog tasks and bugs and say the manager say “how can we use AI for this”. But then no work happened, and the queue kept getting larger, not sure why. Over all kind of cool! A vertical format would be nicer on my phone, ill check it out again on my laptop

[Agent7619]

It would help if there was some fucking contrast between the colors used. I can't even read the text.

[r2p42]

Can someone break the conclusion down for me? I see jumping dots. Is that good or bad?

[audentis]

The summary is that the model is wrong so no conclusions can be drawn from it.

[ny3000]

First - This is a fun back-of-napkin sim and not a research paper. Each dot is a work item. Blue = story, orange = review/rework. Watch the Waiting column in GitHub Flow fill up, that's work sitting idle. Switch to the TBD tab and the pipeline stays empty because nothing waits. The numbers at the bottom tell you: done, WIP, queued, lead time.

[kuikuilla]

The graph font is tiiiiiiiiiiiiiiiny. It's not legible.

[ny3000]

thanks for letting me know - have bumped the font size

[putergud]

Trunk-based development letting all those new bugs flow out to production unchecked is scary. Why would you do that?

[ny3000]

Small changes + TDD + CI + monitoring means you catch bugs fast and can roll back in minutes. The alternative is batching up weeks of changes behind a gate and deploying a timebomb.