I like this, but it violates one of my norms, haha.
Stories can last for a while, but long-lived feature branches have to be kept in sync with the main branch, otherwise they develop nasty merge conflicts and you are not deploying continuously.
I think the better solution is for your versioning and your issue tracker to be integrated: we still expect every developer to merge to mainline one or twice a day[1], keeping merge conflicts shallow... But they should mention what issue they are working on in the commit, and the integration dumps that information into the tracker automatically.
[1] This is not hard to make safe, though it makes a lot of devs skittish at first. See Three-Flow for a non-CD version, https://www.nomachetejuggling.com/2017/04/09/a-different-bra... as a stepping stone. One key thing is that code review needs to become much lighter than it is at many organizations, “I don't care how you did it as long as it can be turned off with a feature toggle and does not break prod or introduce security vulnerabilities when I merge it: those key things are what I am looking for.”
> I don't care how you did it as long as it can be turned off with a feature toggle and does not break prod or introduce security vulnerabilities when I merge it
Does this not lead to poorly-written features that drag down future development yet cannot be turned off because they have grown important for the business?
At least that's my experience with not regulating at least a basic level of code quality in the review. What are you doing differently to prevent that?
You can check in git if work has actually begun, and you can get from and old commit to Jira by virtue of the merge commit.
I don’t know how you’d do it in a non-mono repo setting