5 ms·

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 large

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/ https://trunkbaseddevelopment.com/ that you can point to as something better.

disruptiveink 8mo ago
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 8mo ago
  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.
  - dcrazy 8mo ago
    Until you have a customer that must stay on v.previous for extra time for some reason.
    - QuercusMax 8mo ago
      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.
  - plorkyeran 8mo ago
    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.
- deleted 8mo ago
  [deleted]
mort96 8mo ago
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?
- whoknowsidont 8mo ago
  Nope. Gitflow is not trunk based development.
  - mort96 8mo ago
    Then what's different other than the names of the branches?
    - whoknowsidont 8mo ago
      https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/
- judahmeek 8mo ago
  The TBD website actually has a section comparing GitFlow & TBD: https://trunkbaseddevelopment.com/alternative-branching-models/#gitflow-and-similar https://trunkbaseddevelopment.com/alternative-branching-mode...
whoknowsidont 8mo ago
> 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 8mo ago
  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 8mo ago
    > 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 8mo ago
      >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 8mo ago
        > 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?
whurley23 8mo ago
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

disruptiveink 8mo ago

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 8mo ago
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.
- dcrazy 8mo ago
  Until you have a customer that must stay on v.previous for extra time for some reason.
  - QuercusMax 8mo ago
    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.
- plorkyeran 8mo ago
  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.
deleted 8mo ago
[deleted]

mort96 8mo ago

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?

whoknowsidont 8mo ago
Nope. Gitflow is not trunk based development.
- mort96 8mo ago
  Then what's different other than the names of the branches?
  - whoknowsidont 8mo ago
    https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/
judahmeek 8mo ago
The TBD website actually has a section comparing GitFlow & TBD: https://trunkbaseddevelopment.com/alternative-branching-models/#gitflow-and-similar https://trunkbaseddevelopment.com/alternative-branching-mode...

whoknowsidont 8mo ago

> 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 8mo ago
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 8mo ago
  > 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 8mo ago
    >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 8mo ago
      > 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?

whurley23 8mo ago

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