Use a code freeze as a reminder that there are still quirks to be worked out, and make an effort to work them out.

Today I go on record admitting I don't always use TBD, I do sometimes use long-lived branches, and I sometimes even share a branch with another dev.

A group of people with a lot broader experience than I have, come up with a pretty good definition of "Minimum Viable Continuous Delivery".

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

The best, game-changing ideas always feel like utter blasphemy the first time I hear them.

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

The panel jumps in and discusses the Minimum Viable Continuous Deployment from the manifesto on the web and discuss where they agree and disagree with the requirements listed there and clarify some of the ideas in the document.

Does your team face code freezes? What's preventing you from using trunk-based development and continuous integration to thaw your code once and for all?

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.