6 ms·

This was terrible at the time and it remains terrible now. Extremely few teams need this level of complexity and some parts of it – like the redundant long-live

This was terrible at the time and it remains terrible now. Extremely few teams need this level of complexity and some parts of it – like the redundant long-lived develop branch – are pointless safety blankets. It seems to have only caught on because a lot of people felt adrift when it comes to Git and this was written far too authoritatively for what it is. I’ve seen so many small teams tie themselves up wasting time working for Git Flow that I think this might actually be the worst thing to ever happen to version control. I’m glad the author has mostly walked it back, but unfortunately the damage has been done. If you are putting a team together and haven’t picked a Git workflow and are unsure what to do, start with something simple like trunk-based development and add complexity if and when you encounter problems that justify it. https://trunkbaseddevelopment.com https://trunkbaseddevelopment.com Previous discussions: Please stop recommending Gitflow: https://news.ycombinator.com/item?id=22485489 https://news.ycombinator.com/item?id=22485489 GitFlow considered harmful: https://news.ycombinator.com/item?id=9744059 https://news.ycombinator.com/item?id=9744059 The problem with Git Flow: https://news.ycombinator.com/item?id=23622071 https://news.ycombinator.com/item?id=23622071

Anon_Forever 3y ago
From your linked source: >* main for the Git community since 2020 (master with unsavory connotations before) That was fake news. There were no "unsavory connotations" before. I can safely discard anything that author states from then on. EDIT: And like clockwork, the author has #BLM and pronouns in his profile.
richbell 3y ago
Thank you. This blog post is responsible for more toil than anything else I can think of. > It seems to have only caught on because a lot of people felt adrift when it comes to Git and this was written far too authoritatively for what it is. I think "Git Flow" was successful for the same reason that Javascript "Standard" linter was: misleading branding that lends credibility.
kstrauser 3y ago
It seemed much beloved by teams who’d used SVN or other source controls that had incremental version numbers, switched to Git, and strongly wanted to implement their old workflow in Git. I worked at a shop that tried really hard to pretend that it was possible to strictly order commits (“What if dev A writes commit 1234, then dev B writes commit 5678 and pushes it, then dev A pushes 1234. Which came first?” “The earlier one!” “What does ‘earlier’ mean here?” “Why can’t you just do it!”) and they thought Git Flow was the greatest thing ever. Put another way, it was popular among the same people who write every language as though it were their favorite. Have Python but they only have Java experience? All their Python looks like Java! Well, they thought Git Flow was spiffy, too.
- capn_duck 3y ago
  This is the second comment I've seen in this thread comparing "Gitflow" to what was typical in SVN. Having been there when SVN was in vogue, I can assure you that our process looked nothing like Gitflow. SVN encourages what we now refer to as "trunk based development". The default branch was even called "trunk".
  - kstrauser 3y ago
    I was used to SVN too, and you’re right about the trunk bit. I’m mainly talking about SVN’s nicely linear revision numbers and how it was unambiguous that r23 came after r22. That’s the part that GitFlow adherents wanted to simulate.
- flohofwoe 3y ago
  I used SVN extensively since the early 2000's, and while I still don't like git (at least for projects that also involve non-coders), I liked git-flow even less (and as the sibling poster said, SVN encouraged a much simpler trunk-based development model). My impression was that git-flow was pitched by people who didn't have much experience with other version control systems and were also new to git.
- rewmie 3y ago
  > it was possible to strictly order commits This holds no relevance at all. Nothing in gitflow calls for strictly ordered commits. Just because there is a branch represented with semver that does not mean that the revision control system is involved in versioning.
hsn915 3y ago
> It seems to have only caught on because a lot of people felt adrift when it comes to Git and this was written far too authoritatively for what it is. My hypothesis is the design of the page and the images played a big role in convincing people this is "legit".
albert_e 3y ago
Thanks for this insight. This is useful advice for those who are re/discovering some of these practices for newer projects and would benefit from adopting a more saner approach. I see a reference to GitHub Flow which seems to make sense: https://docs.github.com/en/get-started/quickstart/github-flow https://docs.github.com/en/get-started/quickstart/github-flo...
atomicnature 3y ago
Agreed. In my teams, I've always implemented a simple model, which hasn't failed me. Main branch triggers deployment, and name rest of the branches <author>/<feature>. Just works. In some cases, an extra caveat to the above was triggering deployment/build in Main, only when the tag/version number gets incremented.
- rewmie 3y ago
  > Agreed. In my teams, I've always implemented a simple model, which hasn't failed me. Main branch triggers deployment, and name rest of the branches <author>/<feature>. Just works. So you work with a small team that does not need to put together releases nor does have quality assurance engineers verifying your code before it's released. That's perfectly fine. Your team also has the luxury of pausing any additional development work while lining up a release. That's cool too. Perhaps you don't even have releases, and just continuously integrate everything you throw at it to deploy it somewhere and rely on a multi-stage pipeline to catch problems. That's fine. That's also not the usecase for gitflow. I don't think it's a good idea to project your team's needs to absolutes, and pretend that just because you don't benefit from a process it means none do.
  - atomicnature 3y ago
    You are making too many assumptions in the answer there; most of the things you assume about me, my team or experience are not correct :) I do think the gitflow model is over-complicated.
xwowsersx 3y ago
Strong agreement with everything you've said here. I can't say enough good things about trunk-based development. I started managing a team with 15+ developers. They had used long-lived branches, with a develop, a staging, and a release branch. Not using TBD, "releases" were a huge ceremony and extremely inertial. Velocity went way, way up when we adopted TBD. It took some time for people to become comfortable with the new approach, not because it's complex, but precisely because they had grown so used to unnecessary complexity and had to unlearn many things.
- rewmie 3y ago
  > Strong agreement with everything you've said here. I can't say enough good things about trunk-based development. I don't agree. Git flow is just trunk development applied to release-centric, non-web projects, after you learned very basic lessons on how to put together a production-ready release. There is absolutely no good reason to advocate in favour of ignorance and force you to reinvent the wheel on a process that exists for decades. Failing to understand these needs only set you up to learn hard lessons the hard way at a time you least want to learn them: when Product is pushing you to release the damn thing and asking you why you are incapable of just posting a bugfix over a previous release.
  - ozim 3y ago
    Second that. If one names development=trunk it is the same. In git flow team also should not be active on release branch, it should only be fixes for the release and release branches should not be long lived. Well you might have staging or acceptance main branch but you don’t use it like long lived branch once you start release development/trunk becomes new truth so team should not maintain these “branches” really. Developers worry only about trunk/development an their own feature benches in git flow. For me it is exactly the same as TBD.
  - WorldMaker 3y ago
    In my experience, git tags are far more effective at managing releases than git branches. Each version is released once and only once. The relative immutability of a tag is a higher guarantee of success than the merge swamps that long-running release branches can sometimes become. If you need a bug fix to a previous release you check out the tag of the past release into a new short-lived branch, PR what you need to for the bug fix to that branch (and also any long term changes to the trunk branch), similarly version tag any releases made from the short-lived branch and then delete it.
gonzo41 3y ago
The article suggests *GitHub Flow* not Git-Flow. Which from reading does just seem like trunk based development. After a while, I think we all just end up there from exhaustion.
- Kwpolska 3y ago
  The article is the original git-flow article. It suggests GitHub Flow for projects with continuous deployment and no version numbers in a 2020 addendum, but otherwise, it's the overengineered git-flow.
wodenokoto 3y ago
I agree. Seeing this again with the added “successful” attribute made me think: “successful at what?” At influencing developers? Yes. At helping developers? I want to say no. I don’t want to blame the author for this catching on, but I don’t think it was helpful that it did.
the_gipsy 3y ago
Personally, I simply don't want to see any merge-commits, ever. Merges are hard to follow and may include conflict resolutions which are hard to show (if they show up at all). Sure, "merging" is an amazing feature. But I am not working on projects with an organizational complexity like the Linux kernel. Short-lived & rebased branches so that code gets integrated into main fast. Conflict resolution is never postponed nor shared. Versioning/release/deploy/rollback is dealt with mostly outside of git, or with tags-on-main at most.
- yakubin 3y ago
  Merge commits also break regression finding, since if you checkout a commit that was part of a merge, you land in a tree state reflecting what tree at this commit looked like before the merge, which is a state the master branch has never been in. It often breaks things which work both before and after the merge commit. So you can never find with certainty the regression point at commit level, other than locally linearising this merge into a series of cherry picks. It’s just awful.
  - dbt00 3y ago
    --first-parent, and both with git bisect and many other things, is your friend here.
    - yakubin 3y ago
      That doesn’t fix the issue I described. It leads to a situation where you can say that a merge introduced a regression, but you don’t know which of the merged commits did, because it skips over them all. So it’s not commit-level.
  - leghifla 3y ago
    On the other hand, rebasing can create its own problems re: regression finding If you rebase more than one commit, you can also have an intermediate commit which does not run fine, or even compile. This can happen silently, without conflict resolution while you rebase. Think a function call in trunk needs one additional parameter. So you have a commit message saying "Protocol X tested successfully with Y", which was true when the code done and tested. After the rebase, it might not run anymore because of changes done in the trunk. You will probably notice it and correct it in a later commit, but good luck in 3 month when someone points a bug at protocol X and you want to re-run the test in this commit...
rewmie 3y ago
> This was terrible at the time and it remains terrible now. I strongly disagree. This branching model didn't came out of the blue. This branching model is a direct mapping between regular run-of-the-mill release processes for applications intended to be delivered and installed by the general public, and how Git implements branches. Let's actually look at the git flow workflow branching model and see what it does. There are: * a develop branch. Where commits/pull requests are continuously integrated as part of the everyday development work. Is this complex? No. * feature branches. Where developers present their changes as part of pull requests prior to merging them onto the development branch. Is this complex? No. Software development platforms such as github and gitlab even support creating them automatically as part of the normal ticket creation workflow, and even support triggering dedicated pipeline workflows. * Release branches. These are used to pick a specific state of the development branch to prepare it to be releasable to the public, and prevent it from receiving additional features. This involves things like bumping up version numbers, update changelogs and docs, flip up feature flags, and more importantly trigger pipeline workflows to generate production-ready installers. These installers are then subjected to build verification tests, manual tests, deployment tests, and Product managers use them to evaluate what users will receive. Is this complex? No. * bugfix branches. What happens if a bug is found in a release candidate? You push a fix, of course. You push it directly into the release branch and afterwards create another release candidate version to be subjected to BVTs and manual tests. You also need to fix the bug in the development branch. Is this complex? No. * The prod branch. Once your release candidates are finalized, you cut a release. This can mean tweaking version numbers and docs again, but the goal is to persist the exact version that was released to the public. Also, if an important bug is found in production, such as a crash, you're going to have to prepare a patch release shipping only a fix for it. This branch is used to fork a new release candidate, tweak stuff like version numbers, changelogs, docs, get the fix in, run regression tests, have Product Managers double-check that the bug is fixed, and release a new version. Is this complex? No. I followed this exact branching model for all non-web projects I worked on for a timespan that goes over a decade. Here's the fun part: I followed it before I even knew this page existed. Why? Because this is what you eventually end up converging to if you are a professional doing professional work with a professional team to deliver a production ready version of a product built by professionals. Why is that? Because real world requirements emerge. You learn the hard way that you cannot pause continuous integration when preparing a release, and thus you need release candidate branches to not block other developers. You learn the hard way that you need to do additional work over a release candidate in order to get it ready for production. You learn the hard way that after you release a version of your app then eventually you will need to scramble to release another version to ship a critical bugfix. You learn the hard way that you need to work in multiple releases in parallel. You learn the hard way that sometimes a release is scrapped because the Product Manager changes their mind and instead of shipping a hotfix we ship additional features. Etc etc etc. Now, there are things in this branching model that might not be ideal. For example, merging release branches back into a single prod/master/mainline branch is convenient as a way to ensure the stable release is front and center in a git repo, but it doesn't work if you need to have multiple releases for multiple versions. In the last few years the teams I worked on ended up not merging release branches anywhere, and just kept them dangling out of the development branch. This helps manage the complexity of a major release bump where you need to continue maintaining both the new and old release versions, and possibly even ship minor/patch versions of the old release.
plugin-baby 3y ago
Agreed, but your linked article on trunk-based development does include this strange idea: > the core requirement of Continuous Integration that all team members commit to trunk at least once every 24 hours
- JimDabell 3y ago
  That’s been the case since day one; it’s not something trunk-based development invented. Remember, continuous integration is literally that – people integrate their changes continuously. It’s not just “we run Jenkins”. https://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitsToTheMainlineEveryDay https://martinfowler.com/articles/continuousIntegration.html...
Cthulhu_ 3y ago
I've worked in an environment where they used git-flow, but it was very much a "traditional" (?) software company; they offered long term support, that is, backporting patches to older released versions, that kinda thing. But they also had long lived branches that lived for like 9 months. It was still manageable because the feature was usually limited to one 'domain', and they usually had only one or two people working on the feature at once.

Anon_Forever 3y ago

From your linked source: >* main for the Git community since 2020 (master with unsavory connotations before) That was fake news. There were no "unsavory connotations" before. I can safely discard anything that author states from then on. EDIT: And like clockwork, the author has #BLM and pronouns in his profile.

richbell 3y ago

Thank you. This blog post is responsible for more toil than anything else I can think of. > It seems to have only caught on because a lot of people felt adrift when it comes to Git and this was written far too authoritatively for what it is. I think "Git Flow" was successful for the same reason that Javascript "Standard" linter was: misleading branding that lends credibility.

kstrauser 3y ago

It seemed much beloved by teams who’d used SVN or other source controls that had incremental version numbers, switched to Git, and strongly wanted to implement their old workflow in Git. I worked at a shop that tried really hard to pretend that it was possible to strictly order commits (“What if dev A writes commit 1234, then dev B writes commit 5678 and pushes it, then dev A pushes 1234. Which came first?” “The earlier one!” “What does ‘earlier’ mean here?” “Why can’t you just do it!”) and they thought Git Flow was the greatest thing ever. Put another way, it was popular among the same people who write every language as though it were their favorite. Have Python but they only have Java experience? All their Python looks like Java! Well, they thought Git Flow was spiffy, too.

capn_duck 3y ago
This is the second comment I've seen in this thread comparing "Gitflow" to what was typical in SVN. Having been there when SVN was in vogue, I can assure you that our process looked nothing like Gitflow. SVN encourages what we now refer to as "trunk based development". The default branch was even called "trunk".
- kstrauser 3y ago
  I was used to SVN too, and you’re right about the trunk bit. I’m mainly talking about SVN’s nicely linear revision numbers and how it was unambiguous that r23 came after r22. That’s the part that GitFlow adherents wanted to simulate.
flohofwoe 3y ago
I used SVN extensively since the early 2000's, and while I still don't like git (at least for projects that also involve non-coders), I liked git-flow even less (and as the sibling poster said, SVN encouraged a much simpler trunk-based development model). My impression was that git-flow was pitched by people who didn't have much experience with other version control systems and were also new to git.
rewmie 3y ago
> it was possible to strictly order commits This holds no relevance at all. Nothing in gitflow calls for strictly ordered commits. Just because there is a branch represented with semver that does not mean that the revision control system is involved in versioning.

hsn915 3y ago

> It seems to have only caught on because a lot of people felt adrift when it comes to Git and this was written far too authoritatively for what it is. My hypothesis is the design of the page and the images played a big role in convincing people this is "legit".

albert_e 3y ago

Thanks for this insight. This is useful advice for those who are re/discovering some of these practices for newer projects and would benefit from adopting a more saner approach. I see a reference to GitHub Flow which seems to make sense: https://docs.github.com/en/get-started/quickstart/github-flow https://docs.github.com/en/get-started/quickstart/github-flo...

atomicnature 3y ago

Agreed. In my teams, I've always implemented a simple model, which hasn't failed me. Main branch triggers deployment, and name rest of the branches <author>/<feature>. Just works. In some cases, an extra caveat to the above was triggering deployment/build in Main, only when the tag/version number gets incremented.

rewmie 3y ago
> Agreed. In my teams, I've always implemented a simple model, which hasn't failed me. Main branch triggers deployment, and name rest of the branches <author>/<feature>. Just works. So you work with a small team that does not need to put together releases nor does have quality assurance engineers verifying your code before it's released. That's perfectly fine. Your team also has the luxury of pausing any additional development work while lining up a release. That's cool too. Perhaps you don't even have releases, and just continuously integrate everything you throw at it to deploy it somewhere and rely on a multi-stage pipeline to catch problems. That's fine. That's also not the usecase for gitflow. I don't think it's a good idea to project your team's needs to absolutes, and pretend that just because you don't benefit from a process it means none do.
- atomicnature 3y ago
  You are making too many assumptions in the answer there; most of the things you assume about me, my team or experience are not correct :) I do think the gitflow model is over-complicated.

xwowsersx 3y ago

Strong agreement with everything you've said here. I can't say enough good things about trunk-based development. I started managing a team with 15+ developers. They had used long-lived branches, with a develop, a staging, and a release branch. Not using TBD, "releases" were a huge ceremony and extremely inertial. Velocity went way, way up when we adopted TBD. It took some time for people to become comfortable with the new approach, not because it's complex, but precisely because they had grown so used to unnecessary complexity and had to unlearn many things.

rewmie 3y ago
> Strong agreement with everything you've said here. I can't say enough good things about trunk-based development. I don't agree. Git flow is just trunk development applied to release-centric, non-web projects, after you learned very basic lessons on how to put together a production-ready release. There is absolutely no good reason to advocate in favour of ignorance and force you to reinvent the wheel on a process that exists for decades. Failing to understand these needs only set you up to learn hard lessons the hard way at a time you least want to learn them: when Product is pushing you to release the damn thing and asking you why you are incapable of just posting a bugfix over a previous release.
- ozim 3y ago
  Second that. If one names development=trunk it is the same. In git flow team also should not be active on release branch, it should only be fixes for the release and release branches should not be long lived. Well you might have staging or acceptance main branch but you don’t use it like long lived branch once you start release development/trunk becomes new truth so team should not maintain these “branches” really. Developers worry only about trunk/development an their own feature benches in git flow. For me it is exactly the same as TBD.
- WorldMaker 3y ago
  In my experience, git tags are far more effective at managing releases than git branches. Each version is released once and only once. The relative immutability of a tag is a higher guarantee of success than the merge swamps that long-running release branches can sometimes become. If you need a bug fix to a previous release you check out the tag of the past release into a new short-lived branch, PR what you need to for the bug fix to that branch (and also any long term changes to the trunk branch), similarly version tag any releases made from the short-lived branch and then delete it.

gonzo41 3y ago

The article suggests *GitHub Flow* not Git-Flow. Which from reading does just seem like trunk based development. After a while, I think we all just end up there from exhaustion.

Kwpolska 3y ago
The article is the original git-flow article. It suggests GitHub Flow for projects with continuous deployment and no version numbers in a 2020 addendum, but otherwise, it's the overengineered git-flow.

wodenokoto 3y ago

I agree. Seeing this again with the added “successful” attribute made me think: “successful at what?” At influencing developers? Yes. At helping developers? I want to say no. I don’t want to blame the author for this catching on, but I don’t think it was helpful that it did.

the_gipsy 3y ago

Personally, I simply don't want to see any merge-commits, ever. Merges are hard to follow and may include conflict resolutions which are hard to show (if they show up at all). Sure, "merging" is an amazing feature. But I am not working on projects with an organizational complexity like the Linux kernel. Short-lived & rebased branches so that code gets integrated into main fast. Conflict resolution is never postponed nor shared. Versioning/release/deploy/rollback is dealt with mostly outside of git, or with tags-on-main at most.

yakubin 3y ago
Merge commits also break regression finding, since if you checkout a commit that was part of a merge, you land in a tree state reflecting what tree at this commit looked like before the merge, which is a state the master branch has never been in. It often breaks things which work both before and after the merge commit. So you can never find with certainty the regression point at commit level, other than locally linearising this merge into a series of cherry picks. It’s just awful.
- dbt00 3y ago
  --first-parent, and both with git bisect and many other things, is your friend here.
  - yakubin 3y ago
    That doesn’t fix the issue I described. It leads to a situation where you can say that a merge introduced a regression, but you don’t know which of the merged commits did, because it skips over them all. So it’s not commit-level.
- leghifla 3y ago
  On the other hand, rebasing can create its own problems re: regression finding If you rebase more than one commit, you can also have an intermediate commit which does not run fine, or even compile. This can happen silently, without conflict resolution while you rebase. Think a function call in trunk needs one additional parameter. So you have a commit message saying "Protocol X tested successfully with Y", which was true when the code done and tested. After the rebase, it might not run anymore because of changes done in the trunk. You will probably notice it and correct it in a later commit, but good luck in 3 month when someone points a bug at protocol X and you want to re-run the test in this commit...

rewmie 3y ago

> This was terrible at the time and it remains terrible now. I strongly disagree. This branching model didn't came out of the blue. This branching model is a direct mapping between regular run-of-the-mill release processes for applications intended to be delivered and installed by the general public, and how Git implements branches. Let's actually look at the git flow workflow branching model and see what it does. There are: * a develop branch. Where commits/pull requests are continuously integrated as part of the everyday development work. Is this complex? No. * feature branches. Where developers present their changes as part of pull requests prior to merging them onto the development branch. Is this complex? No. Software development platforms such as github and gitlab even support creating them automatically as part of the normal ticket creation workflow, and even support triggering dedicated pipeline workflows. * Release branches. These are used to pick a specific state of the development branch to prepare it to be releasable to the public, and prevent it from receiving additional features. This involves things like bumping up version numbers, update changelogs and docs, flip up feature flags, and more importantly trigger pipeline workflows to generate production-ready installers. These installers are then subjected to build verification tests, manual tests, deployment tests, and Product managers use them to evaluate what users will receive. Is this complex? No. * bugfix branches. What happens if a bug is found in a release candidate? You push a fix, of course. You push it directly into the release branch and afterwards create another release candidate version to be subjected to BVTs and manual tests. You also need to fix the bug in the development branch. Is this complex? No. * The prod branch. Once your release candidates are finalized, you cut a release. This can mean tweaking version numbers and docs again, but the goal is to persist the exact version that was released to the public. Also, if an important bug is found in production, such as a crash, you're going to have to prepare a patch release shipping only a fix for it. This branch is used to fork a new release candidate, tweak stuff like version numbers, changelogs, docs, get the fix in, run regression tests, have Product Managers double-check that the bug is fixed, and release a new version. Is this complex? No. I followed this exact branching model for all non-web projects I worked on for a timespan that goes over a decade. Here's the fun part: I followed it before I even knew this page existed. Why? Because this is what you eventually end up converging to if you are a professional doing professional work with a professional team to deliver a production ready version of a product built by professionals. Why is that? Because real world requirements emerge. You learn the hard way that you cannot pause continuous integration when preparing a release, and thus you need release candidate branches to not block other developers. You learn the hard way that you need to do additional work over a release candidate in order to get it ready for production. You learn the hard way that after you release a version of your app then eventually you will need to scramble to release another version to ship a critical bugfix. You learn the hard way that you need to work in multiple releases in parallel. You learn the hard way that sometimes a release is scrapped because the Product Manager changes their mind and instead of shipping a hotfix we ship additional features. Etc etc etc. Now, there are things in this branching model that might not be ideal. For example, merging release branches back into a single prod/master/mainline branch is convenient as a way to ensure the stable release is front and center in a git repo, but it doesn't work if you need to have multiple releases for multiple versions. In the last few years the teams I worked on ended up not merging release branches anywhere, and just kept them dangling out of the development branch. This helps manage the complexity of a major release bump where you need to continue maintaining both the new and old release versions, and possibly even ship minor/patch versions of the old release.

plugin-baby 3y ago

Agreed, but your linked article on trunk-based development does include this strange idea: > the core requirement of Continuous Integration that all team members commit to trunk at least once every 24 hours

JimDabell 3y ago
That’s been the case since day one; it’s not something trunk-based development invented. Remember, continuous integration is literally that – people integrate their changes continuously. It’s not just “we run Jenkins”. https://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitsToTheMainlineEveryDay https://martinfowler.com/articles/continuousIntegration.html...

Cthulhu_ 3y ago

I've worked in an environment where they used git-flow, but it was very much a "traditional" (?) software company; they offered long term support, that is, backporting patches to older released versions, that kinda thing. But they also had long lived branches that lived for like 9 months. It was still manageable because the feature was usually limited to one 'domain', and they usually had only one or two people working on the feature at once.