Hacker News Reader

Comment by iamleppert | Hacker News Reader

I agree 100%. I too tried Gitflow on many different projects, with different skill levels of teams and we ended up pulling the plug on it and going back to "master is always deployable/production". Developers work in feature branches that are small and atomic, with frequent merges into master with corresponding deployments. Breaking master is a critical blocker issue. There's no need for tags, complicated release schedules or processes following this model and it scales from a team of 1 to a team of 1000, I've seen it done.

Gitflow doesn't work in a CI environment on a modern software application that has good testing culture and systems that are resilient to failure.

Tools and processes work a lot better when they work for you, not the other way around. KISS.

View on HN

I have used gitflow successfully for some time (starting when it was first announced and there wasn't anyone complaining about it). I've always done "develop is always deployable to production" and the only thing we used master for was rolling back (extremely rare), and the only thing we used release branches for was demos or documentation before a release went out. We had CI built against develop but also every feature branch and every PR. We also leveraged static analysis the same way, and at one company even ran automated pen tests on develop and PRs.

I don't know if I fundamentally misunderstood gitflow but this was my take on it from the beginning and I've never had issues with it that made me want to jump ship.

We didn't use hotfix or support branches, and we never really used tags for anything either. Not using them didn't cause any noticeable overhead.

The nice thing about git-flow in my opinion is that you can implement it without all of the CI stuff, then add that later over time. This is a godsend when you take over a legacy product with little to no test coverage and no CI pipelines.

I've also never run into a ton of merge conflicts, but the largest team I've had is 70 people so maybe it breaks down at some point that I haven't experienced yet.

How can develop be always deployable to production? That doesn’t even make sense in English.

Simple. It’s either the wrong label or we are missing info on the setup.

In my setup I have a develop branch and the idea is that anything in it can be deployed to prod. Of course, that is if nothing fails.

If nothing fails, it merges with master (what’s actually on prod).

You need to learn English. What’s the definition of in development?

I think your last paragraph is pure gold and encapsulates the point of all these discussions.

Use something by applying it with common sense, in the right amount and customization and it will have a chance to work.

Use something as if it is a religion and it will introduce weird side effects.

> Gitflow doesn't work in a CI environment on a modern software application that has good testing culture and systems that are resilient to failure.

Sure it does.

It isn't necessary in such a culture if there aren't bureaucratic barriers to continuous deployment which limits you to continuous delivery.

If you have such barriers, you very quickly need Gitflow’s split between permanent “develop” and “master” branches as well as temporary “release” branches.

> There's no need for tags, complicated release schedules or processes following this model and it scales from a team of 1 to a team of 1000, I've seen it done.

How do you roll back in a process like this? I was imagining that a release would consist of tagging master, so a rollback would be going back to the previous tag. Or perhaps you just keep track of the previously deployed commit hash and roll back to that?

Reply on news.ycombinator.com