I've been using the same convention for over a decade, and it works with a lot of different agile tools:
[<ticket action> TIcket Number] action, in the imperative form (<ticket action> <additional ticket numbers>)
If my code isn't descriptive enough or the ticket doesn't cover enough
of why this code should be implemented this way, I write a little bit more
in the long description, although this is a rarity.
Here is an example:
[starts API-1234] refactor user widget to show avatar [wont-fix API-4356 blocks API-2543]
Adding the avatar here blocks the ability of the user to see the logo (API-2543)
I rarely use the long description due to better tooling and code design. If my code is self-documenting and my tooling allows me to see all changes in a commit easily, I should be able to discern the reason for any particular change without much effort, if any.