In a professional setting, companies usually want this information to live in the issue tracker. Mainly to provide insight to managers/other teams without looking at commit messages.
But it removes the information from the code: you now need to look at the issue tracker to make sense of changes, eg when looking at the history of a file, or with git-blame.
I'd argue that all relevant information that affects the code and architecture of the specific repo should live in commits. They should not only tell you what was changed, but also why; and provide enough context to understand the change in the scope of the repo.
All information that is not directly tied to the code, eg cross-repo/product/etc concerns can go in the issue tracker.
Of course this only works well with a `git commit --fixup` and squash + rebase / squash + merge workflow.
And with monorepos it also becomes a tooling problem.
In a professional setting, companies usually want this information to live in the issue tracker. Mainly to provide insight to managers/other teams without looking at commit messages.
But it removes the information from the code: you now need to look at the issue tracker to make sense of changes, eg when looking at the history of a file, or with git-blame.
I'd argue that all relevant information that affects the code and architecture of the specific repo should live in commits. They should not only tell you what was changed, but also why; and provide enough context to understand the change in the scope of the repo.
All information that is not directly tied to the code, eg cross-repo/product/etc concerns can go in the issue tracker.
Of course this only works well with a `git commit --fixup` and squash + rebase / squash + merge workflow.
And with monorepos it also becomes a tooling problem.