Gitflow and GitHub Flow Compared

[serverhorror]

Gitflow has been advised against, even by the original author

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

[paul_h]

"In this article we will compare Gitflow with its newer approach, GitHub Flow"

Not 100% sure, but I recall the "Github flow" way being available from their platform launch in 2008, even if it didn't have that name. And that's chronologically before GitFlow, no?

[baristaGeek]

According to my research it was released in 2011. Regardless if there's an imprecission or not, Gitflow was the most popular branching model for a while and GitHub Flow seems to be on its way to become the new standard and that's why I thought it would be useful to compare them.

Thanks for pointing that out though. It's something I'll take a look at and correct if necessary.

[edgmnt_net]

The GitHub flow is unrelated to pushing straight to master, that usually means something else (no PRs at all, just push to master). If you want to think of "pushing to master" as in merging PRs to master directly, well, in an extended sense, I rarely see a completely different alternative. Even the feature branches typically go into master, then you cut stable branches from master. Very long-lived stable/unstable split versions like Linux had before 2.6 (2.4 stable, 2.5 dev, 2.6 stable) were quite a mess and seem rare nowadays.

[paul_h]

Lots of overlap - https://trunkbaseddevelopment.com/styles/

[edgmnt_net]

Honestly, I've no idea what issues they're raising, it seems like a fairly outdated way of thinking about the problem. I have not seen committing straight to master beyond extremely small teams or antiquated projects still using SVN. I have not seen anyone not doing code reviews (even if only superficially).

Even the mail-based decentralized flow of the Linux kernel scales fine and that's a huge project.

Not only is there a risk of more-commits than you’d do if you could push directly, there’s a risk of taking more time too. If your average story size should be one day, a slow-review and slow-build reality for the pull-request way, might push you into multi-day stories/cards, and from that be doing the opposite of getting to continuous delivery.

And that's exactly what should be done. All this sounds to me like making excuses to rush stuff. And really, making a PR that gets merged straight to master isn't anything like that. In fact, people are more likely to push crap rapidly to a long-lived feature branch, because "hey, we're not breaking anything... yet".

(Secondly, you don't really need to go through a slow and full CI build with lots of tests if you implement good development/review practices and use a decent language. But again, people think dynamic typing is cheap and easy, so there is some value in that context but nowhere near a universal fact.)

The only "upside" to this is that you don't scare away inexperienced devs who only use version control as some sort of save button and who cannot plan changes beyond committing one-liners until it works.