[perlgeek]

A reason that we are switching from full git flow to a reduced model (basically one master branch + feature branches, occasional hotfix branches) is that git flow isn't compatible with continuous integration and continuous delivery.

The idea of CI is that you integrate all commits, so you must integrate the develop branch - build the software, run the tests, deploy it to a production-like environment, test it there too.

So naturally, most testing happens in that environment; and then you make a production release starting from the master branch, and then install that -- and it's not the same binary that you tested before.

Sure, you could have two test/staging environments, but I don't think I could get anybody to test their features in both environments. That's just not practical.

[briHass]

Is this more a limitation of your CI/deployment tools? What we do (not saying it's the true way) is have TeamCity automatically build both master (production code + hotfixes) and development branches. Our deployment tool (Octopus) can just grab a particular release (e.g. 1.1.500=master 1.1.501=development) and send it to the server for testing. Hotfixes would be committed to master and tested with a build from there.

I guess this does open up the possibility that merging master (with hotfixes) back into development could cause a regression, but we certainly try to keep hotfixes minimal and simple.

Now database changes...that's the real pain point. Both master and development need their own DB to apply changes scripts to. Otherwise, deltas from development make testing master an issue.

[krisdol]

At my last company, that was 60 live feature/bug branches, each having to be built by CI before being mergeable. The feedback loop was huge, and at the end of the day, the quality of the product did not improve over SVN. develop was a shit show and twice a month, master would be as well.

Ultimate they decided to move to team branches, where each team branch was free to operate how they want so long as the team branch itself built successfully before merging into master. I think most teams adopted the more natural-feeling GitHub Flow.

Personally, for me it's not even the god-awful history that makes me despise gitflow, but its reliance on additional tools to effectively manage the process. This should be a huge red flag to anyone seeking to change a process, and it's complained about a lot. Cowokers not knowing what git-flow is doing under the covers is dangerous. I consider myself pretty versatile with git at this point, but I have no idea what the tool does under the covers. I'm sure I could find out; however, when you're handed a piece of software, generally you learn the contract/api it provides, but most of us aren't going to delve into the implementation details.

[perlgeek]

Sure, our CI tool can run the unit tests from all the branches, but we don't have an environment for every branch where we can roll out the software, and do manual tests and automated acceptance/integration/smoke tests.

So if you have just one environment for testing, you can decide to deploy the develop branch to it, in which case you deploy untested builds (from the master branch) to production.

Or you can decide to always deploy the master branch to the testing environment, in which case you have to do a release each time you want to show somebody your progress (and you can't easily show it in dev); that's just annoying extra work, and goes against the idea of continuous integration.