As to posting good commit messages, let us turn to Linus Torvalds and his Git project for guidelines.
Torvalds describes his rules as given below [1].
Also, please write good git commit messages. A good commit message looks like this: Header line: explain the commit in one line (use the imperative) Body of commit message is a few lines of text, explaining things in more detail, possibly giving some background about the issue being fixed, etc etc. The body of the commit message can be several paragraphs, and please do proper word-wrap and keep columns shorter than about 74 characters or so. That way "git log" will show things nicely even when it's indented. Make sure you explain your solution and why you're doing what you're doing, as opposed to describing what you're doing. Reviewers and your future self can read the patch, but might not understand why a particular solution was implemented. Reported-by: whoever-reported-it Signed-off-by: Your Name [email protected] where that header line really should be meaningful, and really should be just one line. That header line is what is shown by tools like gitk and shortlog, and should summarize the change in one readable line of text, independently of the longer explanation. Please use verbs in the imperative in the commit message, as in "Fix bug that...", "Add file/feature ...", or "Make Subsurface..."
As to the details of a commit, from here we read what follows:
Description: arbitrary number of maximum 72 characters long lines, at most one blank line between them (This part is optional. For trivial commits you may not want to write any details at all.)
As for dots ending sentence-syntaxed commit messages, it seems an established standard to omit the trailing full stop: both Linus Torvalds [2] and the Git project [3] follow this convention.
Useful commands to inspect your commit history are: git log, git shortlog, git show, git diff, git show --stat, git log --stat.