The Problem with Git Flow

Re:The Problem with Git Flow by thaumaturgy on Wednesday June 24, 2020 @03:28AM (#23625117)

Yep. What you're describing was used at GitHub [1], at least for a while. I've had a lot of success pitching it to small dev shops that have struggled with more complicated branching models, including git flow. I'm pretty sure git flow became popular just because it was the top search result for "how to git".

Other criticisms of git flow and alternative branching procedures have come up over the years [2] and been discussed here [3][4][5].

A good, simple metric for whether your team is using git well or not is how often a developer is forced to play Guitar Hero [6] just to fix up a bad merge or rebase. The ideal answer is "never"; if it's happening more than a couple times a year, something's wrong.

[1]: https://gist.github.com/jbenet/ee6c9ac48068889b0912

[2]: https://barro.github.io/2016/02/a-succesful-git-branching-mo...

[3]: https://news.ycombinator.com/item?id=9744059

[4]: https://news.ycombinator.com/item?id=22485489

[5]: https://news.ycombinator.com/item?id=11190310

[6]: https://twitter.com/HenryHoffman/status/694184106440200192

[ Parent | on HN ]

Re:The Problem with Git Flow by donmcronald on Wednesday June 24, 2020 @03:53AM (#23625289)

That guitar hero thing is hilarious.

Git flow is something I spent a lot of time theory crafting about years ago. I’d say wasted time, but learning is never a waste and one of the things I learned is the value of deferring complexity whenever possible, especially if there’s no downside.

Using a trunk and tag (that’s what I call it) workflow today doesn’t prevent you from adopting something more complex if the need arises, so it makes a ton of sense for it to be the default on new projects, especially for new developers IMO.

[ Parent | on HN ]