#Git Commits - Best Practices ####Git commit messages are the most important part of a commit, because it's the only place that captures what was changed, and why.
###Rules:
- should be short (because the git comment log doesn't have a lot of space to view copy)
- should be able to sum up the commit in the headline
- be useful
- avoid editorialzing and writing useless messages
- include the issue or bug number if it's a commit fixing a bug
- be detaile (enough). Be succint (keep messages about 1 line or 70 characters)
- be consistent. Follow a similar set of rules as your teammates
- use the active voice 'I just did this thing, and this is the thing I did'. Pick a tense and stick with it.
- commit early and often
- don't change published history
- write a summary and description in imperative mode. Start the line with "Fix", "Add", "Change" instead of "Fixed", "Added", "Changed".
- Always leave the second line blank.
###Example: Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together.
Further paragraphs come after blank lines.
-
Bullet points are okay, too
-
Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here
###Other Interesting things:
- in Git repositories with a lot of collaborators, the commit log can be more valuable as a way of knowing what happened when you weren’t looking.