A team I recently started working with has been using GitFlow. Until last week.

Can we experiment with continuous deployment without completely migrating away from GitFlow first? Here are a couple approaches.

Old habits die hard.

You've decided GitFlow is totally uncool. But what if you're already using it? How can you break the habit?

The odds are in your favor if you follow the science, even though it's not yet settled.

There's almost always more than one way to do something. What workflow does your team use for CI/CD?

Yesterday I explained that GitFlow is anti-agile, but what’s the better alternative? Trunk-based development is the core method I advocate. The one-line summary is: A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’*, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after. main or master, in Git nomenclature There are a number of variations I use in specific situations, but the core practices of meaningful trunk-based development are:

GitFlow is an error-prone waterfall process. It makes continuous integration and continuous deployment impossible. Just avoid it.

Edited by Taavi Kivisik Happy New Year to everyone! I was excited to kickstart the new year with a new position at Lana, a Spanish FinTech startup. As part of my first week on the job, I met a candidate for another position there, and we started talking about controversial opinions in IT. Unfortunately, we found nothing to disagree about. Although I was inspired to catalog a number of my own personal opinions about software development, which may be more controversial.