There are 2 trends here:
1. Everything-as-a-code stored in the git repo in a text format close to the actual source code. If you store documention-as-a-code, diagrams-as-a-code, IaaC, tests-as-a-code, loadtesting-as-a-code, etc. - then why not issues/tickets as a code also?
2. Reduce number of tools/services/mechanisms you use in order to eliminate impedance mismatch, simplify workflows, and remove barriers to collaboration. For example if you standardize on Github, then you can use Guthub Issues, Projects, Packages, Actions, Codespaces, etc. And most developers are already having Github a/c.
This means that to let, e.g., testers add information to a ticket they have to do a code commit? I doubt they want to deal with that, and I don't particularly want to extend commit access to my repo to everyone who might need to interact with an issue.
Fossil SCM has all of the ticketing/bugs stored in the source control repo. Of course, in this case the repo is a SQLite database.
Postmodernism gets a bad rap from modernists as being anti-Truth, and you can see this somewhat in how a Subversion diehard might view Git, “okay but what is the real truth of the code?” Git had this from kernel development, the real truth is that there are about a million different Linuxes out there due to combinatorial explosion, this one is kernel 4.15 with patches X, and Y applied, that one is 4.15 with X and Z applied...” It's not a philosophical choice but a practical reality for Linux. And so too, branch names in Git generally have process associated with them, they have to get their meaning by sociopolitical agreement among the developers and their tooling.
This conspicuous reference to tooling highlights something really important. Git’s postmodernism is constantly clashing with the modernism of Prod. We expect our websites to have one canonical authoritative Truth, at least until we start really committing to postmodernism making A/B testing etc. the norm.
You see this last point particularly in the context of Gitlab and GitHub doing CI/CD tasks.² And indeed now the general wisdom is to do trunk-based development, in other words try to ditch postmodernism at this level, thinking that way is too hard when we've got such a modernist reality in front of us, let us instead bound our postmodernism in modernism-plus-feature-toggles or or so.
Anyway, the reason I'm ranting about all of this to you is that the same modernism/postmodernism tension is present for issue tracking. Yes, logically an issue should be closed by a commit that fixes the issue. This means that an issue can be closed in production and still open in some feature branch, say. Makes perfect sense. Especially this plays well with one piece of advice I am always giving people, which is that the size of your repository, monorepo vs mini-repo, should be at the level that it makes sense to time-travel on.³
Except: we might like a very modernist view on our issues. We might want them to have a single known status, some person worked on it and finished it and now it is done. We want this issue to be in a Kanban board, say. Does a new issue get merged into all of the release candidates? Those sorts of questions. So again, trunk based development may be necessary to mitigate the mismatch.
[1] Postmodernism means a lot of different things to a lot of people. For a quick perspective to help this comment make sense, I take postmodernism as saying that there are blind-sages-and-the-elephant problems for any sufficiently interesting topic: there are multiple perspectives which each give you a partial truth, and only by seeing something from many perspectives do you get a well-rounded education on it. Furthermore, if people are saying “they're actually is only one correct perspective, one sage is Correct above all others, and it is This One” then that is best interpreted not as a genuine criticism of other ideas but as a power grab of sorts—the problem is sociopolitical and not technical.
[2] How do you configure those tasks? “With a file in the repository.” Oh, you mean a CI/CD branch that has one particular name and sets the rules for all branches, per modernist requirement? “No, like in the root of each branch’s folder structure. Like the prod and develop branches will both say “if my branch name is ‘prod’ then deploy me to production,” but this will only trigger for the one branch.” And if I push up a new branch called “hotfix” that says “deploy me to production if my name is ‘prod’ or ‘hotfix’?” Um, er, ah. This is a hard problem that both companies had to invent some sort of external-to-repo tooling for, because they both failed to understand the most basic thing about Git! You want a different take, look to Gerrit. ACLs are in the refs/meta/config branch—ah!
[3] That is, if you have microservices and it makes no sense to roll back one microservice 30 days without rolling back another, which will probably be using some new functionality that was added to the first—then you should version both together even if you build/release separately. (Git lets you get subtree hashes for this pretty easily.)
There is a certain strangeness that we have a very distributed and local notion of code, but _running_ that code (even in local environments) is much harder.
https://reproducible-builds.org/ https://bootstrappable.org/
Everything on PyPI is just random artifacts uploaded by whoever ran a build script on their machine - it's nuts.
The biggest issue was, the magic we'd come up with to prevent spurious closing/opening of these issues was insufficient for formatting and reorganization, and it resulted in unnecessary churn in the issue tracker and for some comments on these issues to be lost. But done better I think it could still be valuable.