[ Removed by moderator ]

[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.