#How to write an individual commit message:
Keep it concise and consistent.
##The Seven Rules of a Great Git Commit Message:
-
Separate subject from body with a blank line: Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, git-format-patch(1) turns a commit into email, and it uses the title on the Subject line and the rest of the commit in the body. When a commit merits a bit of explanation and context, you need to write a body
-
Limit the subject line to 50 characters
-
Capitalize the subject line
-
Do not end the subject line with a period
-
Use the imperative mood in the subject line: Imperative mood just means "spoken or written as if giving a command or instruction". A few examples:
Clean your room Close the door Take out the trash
One reason for this is that git itself uses the imperative whenever it creates a commit on your behalf. So when you write your commit messages in the imperative, you're following git's own built-in conventions. A properly formed git commit subject line should always be able to complete the following sentence:
If applied, this commit will "your subject line here" For example:
If applied, this commit will refactor subsystem X for readability
If applied, this commit will update getting started documentation
- Wrap the body at 72 characters: Git never wraps text automatically. When you write the body of a commit message, you must mind its right margin, and wrap text manually.
The recommendation is to do this at 72 characters, so that git has plenty of room to indent text while still keeping everything under 80 characters overall.
- Use the body to explain what and why vs. how In most cases, you can leave out details about how a change has been made. Code is generally self-explanatory in this regard (and if the code is so complex that it needs to be explained in prose, that's what source comments are for). Just focus on making clear the reasons you made the change in the first place—the way things worked before the change (and what was wrong with that), the way they work now, and why you decided to solve it the way you did.
http://chris.beams.io/posts/git-commit/
https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message