Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

> Well, I suppose this one is correct if you consider dropping even the tiniest part of gitflow as completely abandoning gitflow;

Thank you for that feedback.

It's important to note that my blog post rails against Git-flow as described by that blog post, not necessarily as practiced by teams. If teams drop the problematic parts of Gitflow, of course they'd be able to use Continuous delivery!

But the point of Git-flow is very much to not practice Continuous delivery (the textbook example; again if someone practices what they call CD but it isn't what the textbook says "Continuous Delivery" is, I can't help that.

> See gitflow as a starting point, not as a silver bullet. There are no silver bullets.

Now you're getting to the crux of my issue with the original (has since been updated) blog post. The Gitflow the OP described is problematic for all the reasons I laid out in my post (And more that I didn't list, that others have captured in the comments). It necessarily stands to reason that if you don't take gitflow at face-value, you'll be better off -- but that's not what I'm arguing against. I'm arguing against practicing Gitflow as laid out by the OP.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: