that's from my style guide for my team
in short commits - this is optional - but if more things changed - we should list them explicit so we - can actually see what the intention was-
although I don't mind if the ticket number is in the end or the beginning. It's how the team works it just has to be there. all tier layers are in different repos so I have a git submodule structure, to keep track in gitlab I reference the backend ticket with the frontend tickets and architecture tickets. so you can jump between them if they correlate.
also the commit should be what happens when you apply it not about hat you did
a somewhat related discussion:
My reasoning is ofc debatable.