[iainmerrick]

You’re right. I think what you’re describing is “trunk based development” and it’s much better.

Maybe I’m overly cynical but I think git-flow was popular largely because of the catchy name and catchy diagram. When you point out that it has some redundant or counter-productive parts, people push back: “it’s a successful model! It’s standard! What makes you think you can do better?”

There’s a nice write-up of the trunk-based style at https://trunkbaseddevelopment.com/ that you can point to as something better.

[whoknowsidont]

> but I think git-flow was popular largely because of the catchy name and catchy diagram.

It was because Git showed up in the era of SVN / CVS where those branching models were created because of the uh... let's just call it technical mishaps of those source control systems.

Git did not have the hang ups of SVN / CVS / etc but people stuck with what was familiar.

[zamalek]

Yup, there would have been much less Git buy-in if it weren't for git flow; people grow incredibly attached to their beloved taxonomies.

[throwaway150]

> Yup, there would have been much less Git buy-in if it weren't for git flow

I don't buy this. I've never used git-flow in life. No team I've worked for has ever used git-flow. Yet all of us have been using Git for ages. Git has been hugely successfully independently and different teams follow different Git workflows. Its success has got very little to do with git-flow.

[whoknowsidont]

>I don't buy this.

It's not really debatable. Git flow came about because of SVN / CVS practices and was the first and for many still is THE branching model they use.

>Yet all of us have been using Git for ages

You say "all of us" but then you completely ignore the primary branching model the vast, vast majority of people use on Git.

Just for the record, this isn't being stated in support of git-flow it's just a historical fact that's not really debatable.

[ncphillips]

> the primary branching model the vast, vast majority of people use on Git.

> it's just a historical fact that's not really debatable.

Over my last 15 years of software dev, I have _never_ heard of anyone actually using Gitflow in their codebase.

I'm not saying you're wrong. My experience is anecdotal. But I don't know why you say it's a "fact". Was there surveys or anything?

[zamalek]

I'm not questioning your experience, but how "enterprise" is that experience? Gitflow was no small part of my convincing my company to move off TFVC. I doubt they still use, but it was shallow waters for scared folk.

I strongly doubt that my story, just as much as yours, is unique.

[throwaway150]

> It's not really debatable.

Very weird for you to start a reply like this when we are literally debating it.

> You say "all of us"

Yes, I mean those of who don't use git-flow. That's what I meant by "all of us".

> ignore the primary branching model the vast, vast majority of people use on Git.

Do you live in a git-flow bubble or what? I've been using VCS since the dark ages of CVS. Moved to SVN. Mercurial. Git. Never worked in a team using git-flow. Never used git-flow myself. Never met anyone IRL who uses git-flow. I only read about these things on HN and blogs.

What kind of stats do you have to claim that this is the primary branching model. If I go by my experience, it's a minority branching model that only people living within the bubble care about.

> it's just a historical fact that's not really debatable.

What is a historical fact? That people use git-flow. Nobody is contesting that. What I am contesting is that the success of Git is not connected to git-flow like the grand-grand-parent comment said.

[whoknowsidont]

I'm not debating it... we're not debating it. You're having it explained to you.

>If I go by my experience

That would be the very definition of a bubble.

[disruptiveink]

Correct. If you can always either fix it forwards or roll back, which you should be able to unless you're building software that needs to go out in releases with versions tracked separately that need to keep getting fixes, trunk-based development simplifies everyone's lives greatly.

I've never seen an organisation that insists on release branches and complicated git merge flows to release their web-based software gain any actual benefit from it that isn't dwarfed by the amount of tooling you need to put around it to make it workable to the dev team, and even then, people will routinely screw it up and need to reach out to the 5% of the team that actually understands the system so they can go back to doing work.

[QuercusMax]

I've done branchy development to good effect for user-installable software, where we committed to maintain e.g. 3.2.x for a certain time period, so we had to keep release branches around for a long while.

But for continuously deployed SaaS or webapps, there's no point.

[plorkyeran]

I've worked on software where we had multiple maintained release branches and we always just worked off master and then cut long-lived release branches from master at some point. Once a branch was cut we'd never merge master into it again and instead backport just specific fixes, which is quite different from git-flow.

[dcrazy]

Until you have a customer that must stay on v.previous for extra time for some reason.

[QuercusMax]

Well in that case it sounds like you're shipping multiple versioned instances of your software for different clients, which is much closer to shrink-wrapped software than it is to e.g. gmail.

[whurley23]

I'm in an environment where the work consist of multiple streams. There are long running tasks, major features that can go for months, require multiple rounds of review and approval, and a sustained amp of back-and-forth. Then there are smaller ones that are typically accomplishable within a typical iteration time period. And then you have hot fixes, security or emergency changes.

These all have separate QA, integration, and release timelines that can -- and often do -- change during the process. As a result, what goes into any given release is sometimes being changed almost right up until we hit the button. Having the ability to roll a release branch from different feature branches and not get miscellaneous work from things that aren't ready is important.

Now, this could also be done with clever use of feature flags, but the platform doesn't play nicely with that concept. Plus, then there would be the work of going back and removing them or leaving in place a mess of conditional statements littered around.

Doing it in version control is architecturally simpler, integrates better with our task and version management tools and is easier to standardize on. There is a cost in how to handle merge conflicts, but that is manageable and can be offset by good task planning and careful work. And the occasional reset

[mort96]

If what they described is "trunk based development", then "git flow" is just "trunk based development where the trunk is called develop and there's a branch which always has the latest release". Is that it?

[judahmeek]

The TBD website actually has a section comparing GitFlow & TBD: https://trunkbaseddevelopment.com/alternative-branching-mode...

[whoknowsidont]

Nope. Gitflow is not trunk based development.

[mort96]

Then what's different other than the names of the branches?

[whoknowsidont]

https://trunkbaseddevelopment.com/