Any software project is a collaborative project. It has at least two developers, the original developer and the original developer a few weeks or months later when the train of thought has long left the station. (View Highlight)
With a well written commit message, it is easier to get back in the state of mind at the time you wrote this change. (View Highlight)
When you come back from holidays a simple git log --pretty will give you a lot of information about what your coworkers did while you were away. (View Highlight)
It becomes easier to know why a change was made if the commit message carries real meaning. It makes rebase result much more predictible. (View Highlight)
7 rules to write a good commit message
Separate subject from body with a blank line
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
Wrap the body at 72 characters
Use the body to explain what and why vs. how (View Highlight)
Make core independent from the git client (#171) Upgrade Docker image version (#167) Add maven preset (#172) Add a generic preset using configuration file (#160) Improve error messages for preset system (#161) Publish Canary version on master push (#141) (View Highlight)
Conventional Commits
It is a specification inspired from Angular commit message guidelines. It features a few interesting rules like:
• Commit must be prefixed with a type (feat, fix)
• A scope may be provided to point out a specific section of a the codebase (really interesting for monorepos)
• Breaking changes must be included in a footer section (View Highlight)
