Trunk flow has a lot going for it. Here's a link in case others don't know of/haven't heard about it -- it starts off with a tl;dr summary: <a href="https://trunkbaseddevelopment.com/" rel="nofollow">https://trunkbaseddevelopment.com/</a><p>One of the key elements of trunk flow that I value about it is that "the software you released" is not a living stream. Because of that, it should not be tracked by a long-lived branch with commits that flow in in over time except in rare fix situations. With trunk flow and similar styles, you can always merge to master, and you can always deploy master. You do so by cutting a new branch, and in my opinion, you then build a static artifact. Next time you deploy, you cut another branch, build your artifact, and put it somewhere.<p>Need to do a hotfix, but there's other work since last release that you just can't ship? Cherry-pick onto the <i>currently-deployed release branch</i>, not onto some long-lived production branch. There's no weird merge-backs, no strange no-op commits in a long-lived history.<p>trunk-flow is also very simple. For these and other reasons, it's great.<p>And, some key points about building static deployment artifacts: if you build an artifact to deploy at merge-time to master, you can avoid having your production servers download and execute code for you. You can test your exact artifact before you ever send it to production. You can reproduce your builds. Left-pad-like library unavailability issues can't hit between staging and production. Deployments to production are very fast. You can keep a few artifacts around and roll back quickly and reliably to working states (barring database stuff!). You can deploy two versions to different userbases at the same time. It's very useful. :)