Comment by Ethan Moore on "GitFlow Workflow: The Traditional Branching Model, and When It Still Makes Sense"

Ethan Moore

Good call on the gotcha about merging a hotfix into the open release branch instead of develop. That's the one that bites people, and I've seen it cause exactly the "why is this bug back?" moment you describe. One small tip from experience: a short checklist in the PR template for release and hotfix branches ("merged to main, merged to develop, tag pushed") cut our double-merge mistakes a lot. Do you think GitFlow still pays off for a small team shipping a web app, or only for versioned products?

Atul Vishwakarma

DevOps & Cloud Professional | Technical Writer

7h ago

Really appreciate that, Ethan. A PR checklist is a great practical safeguard, especially for the back-merges and tag pushes that are easy to miss when a hotfix is urgent.

Great question. And it sets up the rest of this series nicely. I’m covering GitHub Flow, GitLab Flow, and Trunk-Based Development in upcoming posts, then wrapping up with a practical guide for choosing based on release cadence, team size, QA needs and deployment maturity. For a small team shipping a web app, I’d usually lean toward GitHub Flow or trunk-based development. GitFlow makes more sense when releases need a dedicated stabilization phase or support for multiple versions.

That makes sense, thanks for laying out the series plan. Choosing by release cadence and stabilization needs is a much more useful frame than picking a model by name, so I'm looking forward to the decision guide.

Search Hashnode