Trunk-based or GitFlow: how to choose a branching model

Every so often a team argues about trunk-based versus GitFlow as if it were a matter of principle. It is almost always a matter of two properties of the product.

Question one: do you maintain several versions at once?

If you sell software with numbered versions and support 3.x while developing 4.0, you need long-lived branches to fix 3.x without dragging in the new work. That is GitFlow or a variant. If all that exists is "what is in production right now", you do not have that problem.

Question two: how often do you deploy?

If you deploy several times a week or a day, long-lived branches become a toll: every merge is large and risky. Trunk-based — integrating into main daily, behind feature flags if something is not ready — reduces batch size and with it the risk.

• One supported version + frequent deployment → trunk-based.
• Several supported versions → GitFlow, even if you deploy often.
• One version + quarterly deployment → either works; pick the simpler one.

The full guide to branching, review and releases is in Git and version control in a team.