The summary should primarily summarize the commit description. And since it can't be long, there is not much space for common format. Treat it like subject if you were sending the description by email (in fact that's exactly what happens in git project itself). That said, there are few hints:
- When fixing bug, by all means include the issue number.
- When completing feature if you have some task identifier, include that.
- If the identifier included goes with subject, it often makes sense to just reuse it.
- If the project is large, mention which component is affected.
- Describe the change in functionality, never the code (that can be seen from the diff).
And try to describe the mental process behind why you changed the code the way you did in the long description. It helps a lot when there is a bug in the code or when somebody needs to change the code later and needs to tell whether strange piece of code is a workaround, obsolete, bug or what.