Git Flow Is A Bad Idea • Dave Farley • GOTO 2022

We’re so pleased to announce that we’ve teamed up with Dave Farley, author of “Continuous Delivery” and frequent GOTO Conferences speaker, for a monthly video series featuring ideas about continuous delivery, DevOps, test-driven development, BDD, software engineering and software development in general.

Dave Farley - Continuous Delivery & DevOps Pioneer, Award-winning Author, Founder & Director of Continuous Delivery Ltd.

ABSTRACT
What is GitFlow and why is it a bad idea if you want to practice Continuous Delivery or Continuous Integration? GitFlow is a feature branching strategy that adds several extra layers of complexity. GitFlow is bad when we need fast feedback and a clear picture of the quality and 'releasability' of our work, so how do we adapt to get that faster feedback and a clearer picture?

In this episode Dave Farley describes GitFlow, Git feature branch-based GitHubFlow and explores the reasons why they aren’t compatible with the software engineering practices of Continuous Delivery, or Continuous Integration, and describes how Bryan Finster got important sources of information on this topic changed to point out their inappropriateness including revising the description of GitFlow on the Atlassian website.

CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses

RECOMMENDED BOOKS
You can grab Dave Farley's new book 'Continuous Delivery Pipelines' here:

#GOTOxDaveFarley #Programming #GitFlow #Git #CD #ContinuousIntegration #DevOps #DaveFarley #GOTO #GOTOcon #ContinuousDelivery

DAVE'S LINKS

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[JJOULK]

Even though I think this time Dave is being a little biased to a narrow not so generalizable experience ("not a silver bullet"), this video has derived in really valuable discussions in the comments section with awesome industry knowledge. It's worth taking the time to read some of the discussions and the points being made. I hope we as an industry continue sharing and learning at every level

[Venthe]

As much as I admire Dave, he is purposefully sacrificing reality on the altar of the thing he deemed 'correct'.

GitFlow is a methodology which works in a certain contexts, like actually having to support multiple versions of the product. This doesn't mean that you can't have continuous integration or even continuous deployment.

Compared to this, trunk based development is easier - but it will not work when supporting multiple lines of product.

Use trunk-based development whenever possible - it's easier on multitude of levels. But, as EVERY SINGLE THING IN THE INDUSTRY it's not a silver bullet. And at this point, Dave is preaching not teaching.

[sethkellas]

My biggest question around CI flow is regarding code review. If my entire team is direct commiting to a deployable branch, when do I get to review the changes my devs are making?
I feel like I lose the transparency into if their code meets standards and fulfills the requirements. It may pass tests and code coverage from our automated review... But it doesn't have the tech leads approval.

[RadOviva]

Does it mean whenever a merge to main branch happens it should be deployed to prod immediately?
Good luck!

[RobGThai]

I think labeling them a bad idea is a bad idea. Both require surrounding agreements and readiness to implement. Sometime you jump into a situation where nothing is in place and the system is bug prone with business rushing to market and lacking understanding of how to develop and test software. In that situation Trunk based is the worst idea you could have. We have to choose the right tool for the right job, labeling some tool bad without surrounding context just seems plain wrong to me.

[mdesnica]

At my current job: Having not only feature branches (which might be not so bad if kept short), but also a dev branch!!! and then a master, is so stupid and I thought that was something that was done in early 2010s.
Instead of deploying a feature branch to a test environment (staging or dev), now we need to merge that stuff to the dev branch and then deploy it to the test environment. If you want to add or change soemthing, you need to go through that waterfallish steps again . 😄

[paulfrischknecht]

we don't have to forgive you, you are right. we do feature branching and it's because we don't trust our automated tests and our ui regression tests are mostly yellow and have no influence on the success or failure of a build and do not gate deployments. How do you get a team where half of people have less than 5 years experience ready for CD?

[jean-alexis.aufauvre]

1/3 GitFlow and GitHub flow allow some level of integration, but aren't compatible with CI. Frequently pulling develop or main isn't CI, there is no integration when features A, B and C are developed in branches and the code is merged only after the features are complete. The only way to do CI is to integrate frequently (pull *and* push) before a feature is complete or to define extra small features that can be shipped in a few hours.

[allmhuran]

I don't care about the flavour of the day.

In our industry we all know that every few years (or months...) someone comes out and says "what you're doing is bad, just do this instead". And the problem always turns out to be that the "just" in "just do this" is never appropriate, because the "do this" ends up being difficult or problematic in some different way. "Just do trunk based"? So... "just" do cherry picking, feature flags, branch by abstraction, and so on. "Just" move complexity INTO the code, and all of a sudden the utopia will come about. "Just" do this even if you only have a hand full of developers at your work and only get merge conflicts a few times a year. "Just" do this even if you work in an enterprise and your UAT step involves a sign off not merely for lack of bugs, but also literal "acceptance" of the product proposed for release, and therefore necessarily involves human work that cannot be done via automation.

Dave might be knowledgeable about some topics, but he is one of the worst offenders in this space, taking on absolutist positions with a religious zealotry.

[Ceko]

I agree with you mostly, and our company uses this workflow. But where it hurts sometimes are the somewhat larger changes that need a release somewhere in the future (to coincede with marketing for example). Hotfixes etc will of course also occur. What’s your take on that?

[loutrea]

GitFlow became a de facto standard. Most of the time teams do not think which flow is the best for their needs. They just choose GitFlow because it's the flow they know. The "git flow" plugin infected so many teams because it makes GitFlow apparently simple.

[opsidao]

Why would I need to "cross my fingers" to know if my changes will work alongside others when doing github flow? Just enforce branches to be up to date with master for merging (which github has supported for years) and you don't need to cross anything, you will know for certain as your changes won't be mergeable unless they're up to date with what's already there.

Also, if you just push your code straight to master, how is it reviewed by your colleagues before being released? Or do you have to manually release master to production? I hope not...

[BenRitchie]

I think the only missing thing here is more on feature flagging and canary releases, but otherwise I agree from my own experiences with TRUNK-based development. But we still catch loads of multi-user race conditions in staging that the Test Pyramid doesn't catch. Perhaps we can build multi-user E2E tests to catch them in future but for now Manual QA has its place.

[Truekingnoctis]

“Everything is bad.” Trend continues.
I have used this for continuous integration in a fully automated scale with dozens of people working in different microservices.
This must be the same trend that says domain driven design is bad.
“Works against continuous integration”
Is really inaccurate, it’s the same as saying pizza with pineapple is bad when you didn’t actually tried it and continued doing the same thing for decades.

[hansvetter]

Each CI/CD-step is/should be a double-step composed of change and test ... and test itself should be a double-step of internal and external tests ... were internal tests are test suites of unit tests for corner cases and such ... but external tests must be implemented through releases for user feedback in order to be "agile" ... release often in small increments (divide & conquer)
... the challenge in all of that is and always will be ... "who tests the test?!?" ...

[FINALLYQQQQAVAILABLE]

14:30 You can always have the build server merging the change to master locally before running tests when using the Github Flow. There's not much point running centralized builds to isolated feature branches anyway. What we want to know is is the branch ready to be integrated. Trunk based flow is certainly the fastest model but I think it requires a very skilled team of programmers. With less skilled programmers half of the suggested changes need more or less fixes to avoid corrupting common code base too much. In a feature branch flow like Github Flow it's possible.

[alexrusin]

This master branch CI works real well when you are developing the first version of your software. But how do you handle hot fixes and bugs when you release in production and in the process of working on version 2? If I merge everything into master and do a hot fix and release it, I may end up with half working version 2 in production as well. This is why I'm confused why git flow is a bad idea.

[sjatkins]

You would really need to assume your tests 100% guarantee you are not going to breaks something important on production. That is one hell of an assumption.

[scottamolinari]

Um, one of the rules of Gitflow I know of is to pull from dev to my feature branch before I start my day. Or, if I know there are people working on code that could have a more definite effect on my work, I'd pull more often. They and I would also know to push more often too. Dev is the control branch. Dev is used for QA. Master is for releasing. If QA is good, it goes to production i.e. goes to master. Gitflow works. You just have to use it properly and your points seem to offer an incorrectly used Gitflow process. Everyone working on master is a really bad idea.

[seanfitzg]

Hi, good video. Just wondering if you cover this topic in your new book?