It's up to your project/company/needs. The purpose is for you to know what the commit was, so as long as you stay consistent it doesn't make much of a difference.
That said, there are some suggestions that git uses for its own projects in terms of phrasing of messages:
The first line of the commit message should be a short description (50 characters is
the soft limit [...]), and
should skip the full stop. It is also conventional in most cases to
prefix the first line with "area: " where the area is a filename or
identifier for the general area of the code being modified [...]
The body should provide a meaningful commit message, which:
explains the problem the change tries to solve, what is wrong
with the current code without the change.
justifies the way the change solves the problem, why the
result with the change is better.
alternate solutions considered but discarded, if any.
But again, this is just the convention that git uses, not a universal standard.
If you use any sort of bug tracker (e.g. JIRA), then it might be helpful to include the ticket number (both for reference and for, say, linking to it), but otherwise as long as you know what the commit is for, you should be OK.