I'm not intending to hi-jack this conversation, but I felt I could provide some insight as a ThoughtWorker. I certainly don't speak for the organisation as a whole, but I can definitely share some thoughts.
I wrote a comment elsewhere in this discussion that partially addresses your question of "what is the alternative (to Gitflow)?". In general I'd say throw away the prescriptive rules about feature/hotfix/whatever branches, and stick to a simple branching strategy that aims to keep the branches as tightly integrated with master as possible (rebase constantly - literally with every commit), and as short lived as possible (think of days as a maximum unit of measurement for branch life. But hours would be better).
I'll preface the rest of this by saying that branching strategies work excellently for projects where there's low developer trust (like an open source project with random contributors). But if you've got a team of folks that you trust working on a product, the following may be useful.
On a more macro level, ThoughtWorks strongly favours Trunk Based Development over any branching strategy in most cases. The ultimate aim of TBD being that every commit made into a repository should be production ready. If a commit causes your CI pipeline to fail, work stops until it starts passing again.
Sounds like a pain in the ass at first. But committing constantly to master and having your code automatically verified in minutes means that if you've introduced a breaking change you know about it straight away - not a few days later when you merge your branch into master. This greatly reduces this risk of entering "merge hell", or just battling odd bugs after a "big-bang" merge.
You raise a very good point about not being able to merge with master frequently because of potentially broken code in your branch/commits. Luckily, we have feature toggles for that. Feature toggles allow us to deploy unfinished work into production, with the work itself being turned off and not available to your end users.
Your tests can still exercise your new code by turning the feature on in the test suite and doing whatever they want. And an added bonus is, that when it comes time to "release" your new feature, all you've got to do is change a boolean flag to true and you're off to the races.
If your new feature breaks stuff. Just turn it back off. No big, scary, patch to write. No panic. Nice and easy. And once your new feature is stable, remove all of the toggles in your codebase - It helps to think of feature toggles like branches in the sense that you should get rid of them as soon as possible after releasing a feature. Stale feature toggles are the worst.
I'd really highly recommend you give TBD a go. Even if it's just in a small side-project to get a feel for what it's like. To get started all you really need is a git repo, a CI tool (like CircleCI or Travis) and a simple, key-value, configuration file for your feature toggles.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
Minor niggle, but catching potential merge issues early isn't a function of your branching strategy and is easy to do without adopting TBD. Just build every branch, and merge in the trunk before you do anything else. If you've introduced a conflict or broken a test someone else wrote in the interim, you'll know about it right after you push. If you wait on testing the merge until you're ready to integrate, you could have problems across multiple commits whether your branch has been alive for hours or days.
I'm not intending to hi-jack this conversation, but I felt I could provide some insight as a ThoughtWorker. I certainly don't speak for the organisation as a whole, but I can definitely share some thoughts.
I wrote a comment elsewhere in this discussion that partially addresses your question of "what is the alternative (to Gitflow)?". In general I'd say throw away the prescriptive rules about feature/hotfix/whatever branches, and stick to a simple branching strategy that aims to keep the branches as tightly integrated with master as possible (rebase constantly - literally with every commit), and as short lived as possible (think of days as a maximum unit of measurement for branch life. But hours would be better).
I'll preface the rest of this by saying that branching strategies work excellently for projects where there's low developer trust (like an open source project with random contributors). But if you've got a team of folks that you trust working on a product, the following may be useful.
On a more macro level, ThoughtWorks strongly favours Trunk Based Development over any branching strategy in most cases. The ultimate aim of TBD being that every commit made into a repository should be production ready. If a commit causes your CI pipeline to fail, work stops until it starts passing again.
Sounds like a pain in the ass at first. But committing constantly to master and having your code automatically verified in minutes means that if you've introduced a breaking change you know about it straight away - not a few days later when you merge your branch into master. This greatly reduces this risk of entering "merge hell", or just battling odd bugs after a "big-bang" merge.
You raise a very good point about not being able to merge with master frequently because of potentially broken code in your branch/commits. Luckily, we have feature toggles for that. Feature toggles allow us to deploy unfinished work into production, with the work itself being turned off and not available to your end users.
Your tests can still exercise your new code by turning the feature on in the test suite and doing whatever they want. And an added bonus is, that when it comes time to "release" your new feature, all you've got to do is change a boolean flag to true and you're off to the races.
If your new feature breaks stuff. Just turn it back off. No big, scary, patch to write. No panic. Nice and easy. And once your new feature is stable, remove all of the toggles in your codebase - It helps to think of feature toggles like branches in the sense that you should get rid of them as soon as possible after releasing a feature. Stale feature toggles are the worst.
I'd really highly recommend you give TBD a go. Even if it's just in a small side-project to get a feel for what it's like. To get started all you really need is a git repo, a CI tool (like CircleCI or Travis) and a simple, key-value, configuration file for your feature toggles.
Minor niggle, but catching potential merge issues early isn't a function of your branching strategy and is easy to do without adopting TBD. Just build every branch, and merge in the trunk before you do anything else. If you've introduced a conflict or broken a test someone else wrote in the interim, you'll know about it right after you push. If you wait on testing the merge until you're ready to integrate, you could have problems across multiple commits whether your branch has been alive for hours or days.
Absolutely, you're right on the money here. I addressed this in my other comment, but it's good to surface this point in this thread too.