Most of this article is nonsense. It's true, gitflow is not a silver bullet for every single situation, and if you've got a more complex situation than a single team working on a single project, you're probably going to need something that takes the complexity of your situation into account. It's also true that gitflow might be a bit too detailed and complex for simpler situations, but you can easily drop parts of it. It's not a universal solution to everything, but it's a decent basis to start from, particularly if you have no idea how else to organise your git workflow. Because everybody using their own approach without any coordination is definitely going to be worse.<p>> <i>"Gitflow abandons rebasing"</i><p>It doesn't entirely do that, but it does abandon rebasing in situations where it should be abandoned. Rebasing is dangerous. Rebasing changes your history, and as any time-traveler knows, messing with history is risky. If you change history that you already shared, you can end up duplicating it and making a mess.<p>Rebasing is only ever fine for local changes, and you can still use it there in gitflow. But if you merge a feature that took some time to develop, into the develop branch, rebasing is a terrible idea, and it should really be done with a merge.<p>> <i>"Gitflow violates the “Short-lived” branches rule"</i><p>Is that a rule? Some features really do take time to develop. Any workflow has to account for longer lived branches. Also, if code has to be reviewed before it can be merged, that also extends the lifetime of branches. Fortunately big merge conflicts are easily prevented by regularly pulling the latest develop into the feature branch.<p>And any situation where you have multiple people potentially changing the same file, is going to lead to merge conflicts no matter what git workflow you use.<p>> "<i>Gitflow makes Continuous Delivery Improbable</i>"<p>Nonsense. Once code has been merged into develop, it's ready to deploy. Well, I suppose this one is correct if you consider dropping even the tiniest part of gitflow as completely abandoning gitflow; all continuous delivery teams I've seen, don't use explicit release branches; they just deploy develop (or merge to master and then auto-deploy that).<p>The only argument the article uses here is "look at all those lines and dots! this can never work!" Well, it can and does.<p>I've worked in teams that use short release cycles, up to daily, and use a workflow that's pretty close to gitflow. It's a decent default to start from, but if you're working in a more complex environment, with multiple teams working on the same code base, parts of which need to be releasable independently from the rest, then yes, gitflow might not fit your need. So adapt.<p>See gitflow as a starting point, not as a silver bullet. There are no silver bullets.