So we need to be a little careful here. Git has won the version control wars, and Git actually reifies a very hard-nosed and pragmatic sort of postmodernism.¹

So we need to be a little careful here. Git has won the version control wars, and Git actually reifies a very hard-nosed and pragmatic sort of postmodernism.¹ 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.)