[agsnu]

I'm not sure I entirely follow the question. We don't attempt to have any tag in the repo itself representing what is "in production" - which itself is sort of a misnomer because of the iOS App Store 7 day phased release functionality anyway, plus of course lag in customers downloading updates onto their devices.

So if you need to patch something after a release branch point, there is inevitably a discussion dependent on the context of where any in flight release is - has it started rolling? if so how far is it? is it already completely rolled out? Are we halting the release or just following it immediately with a hotfix? Do we want the hotfix to go through phased release? We just have a separate dashboard tracking release status.

Jenkins pipeline wise very similar - land on main, will go in the next nightly build. If you need to patch a release, submit your patch to the relevant release branch, and the corresponding beta/production pipelines will trigger. (Release branches are protected and require special approval to merge to.)

[bacro]

So when you need to do a hotfix, how do you know which commit to branch from if you do not tag the releases that were deployed to production?

To me the only additional complication of gitflow to trunk-based development is the existence of the main branch, because you also create a release branch when you want to make a release. Getting rid off the main branch is usually through tagging, but as I mentioned is not easy to automate the tagging when you do not have an additional branch to use in your pipeline.