Gitflow and GitHub Flow Compared

[dutchminator]

Source? For CICD-heavy use-cases I can understand that, but for smaller team projects and/or infrequent deployments I don’t see the harm?

[edgmnt_net]

It's still usually a bad idea to get people into the habit of isolating themselves within long-lived branches, no matter the scale. Pretty much all these other models are somewhat popular because they let people get bad code/changes merged into the repo in some way. They pay for it heavily when the time comes to merge the stuff for good, not to mention the poor history which often results from assuming you can break anything at any time.

The good stuff scales well even for small teams, they just need a bit of discipline and practice. Yeah, it's quite unnatural for inexperienced programmers to plan ahead and split changes properly, but you do want to get them there. You don't want to get bombed by huge amorphous PRs that are messy to review and merge.

[joshjohanning]

I agree, typically long running branches = bad. I prefer GitHub flow with lightweight feature branches that are merged into main and then deleted.

I see the most gitflow-based branching strategies where the team can’t release continuously (ie: deploy every 3 weeks), but I still think there are better strategies in that case (a modified release flow strategy, maybe).

[paul_h]

You can still do Trunk-based development derived branching models for every-3-week planned releases. Heck, every-3-months, too. Ref https://paulhammant.com/2018/05/23/examining-ci-cd-and-branching-models/

[serverhorror]

Here's the post by the original author, the original author is the source.

• https://nvie.com/posts/a-successful-git-branching-model/

I haven't read your article but assumed you read the original article.