So if the “deployed branch” were really just a “tag”, that would fit trunk based development? Because that’s basically what git is doing. It’s not like there are two sets of files anywhere, afaik.
My understanding of this though is that there isn’t supposed to be a difference between “what we’re working on” and “what’s deployed”, which I think then means you don’t really do “long term” development.
I've been working on my product for over 8 years, sometimes alone, sometimes with a tiny team.
I have a mono-repo with one master branch - that auto-deploys to test - and one release branch that auto-deploys to staging.
I can hot-swap my staging and production environment with the click of a button.
Simple, and it allows us to deploy a hotfix of needed, and we've done some major work on master that needs to be validated first...
But,... It all depends on your context and your needs...
Sounds neat, but I still think complexity is removed if the deployment is not directly linked to the code repository. For me the code repositories purpose is to build software, and operation is not it's responsibility.
I prefer having a gitops repository that describes the environment. Completely decoupled from the source code repository. If some automation directly from the source repository is required, a CI job can automatically update the gitops repository and trigger a deployment.
My understanding of this though is that there isn’t supposed to be a difference between “what we’re working on” and “what’s deployed”, which I think then means you don’t really do “long term” development.