that's from my style guide for my team
#<Main-Ticketnr> general description as headline #<other-ticket-references>
- 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
changes XYZ
not
changed XYZ
a somewhat related discussion:
hashnode.com/post/imperative-mood-vs-past-tense-w…
My reasoning is ofc debatable.