It's an opinionated guide I keep with me to consult every time I catch myself in doubt if I'm writing nice commit messages with context of what I'm delivering.
A good commit should complete the following sentence
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>
Commit Sample
See an example of commit below:
[type](optional scope): [subject]
[optional body]
[optional footer]
Types
Must be one of the following:
- build - Build related changes
- ci - CI related changes
- chore - Build process or auxiliary tool changes
- docs - Documentation only changes
- feat - A new feature
- fix - A bug fix
- perf - A code change that improves performance
- refactor - A code change that neither fixes a bug or adds a feature
- revert - Reverting things
- style - Markup, white-space, formatting, missing semi-colons...
- test - Adding missing tests
Scope
A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., feat(parser): add the ability to parse arrays.
Subject
The subject contains a succinct description of the change:
- Use the imperative, present tense: "change" not "changed" nor "changes"
- No dot (.) at the end.
Body
Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
The 7 rules of a great commit message:
- Separate subject from the body with a blank line
- Limit the subject line to 50 characters
- Summary in the present tense. Not capitalized.
- 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
Oldest comments (41)
Really useful article! I end up not focusing on the commit messages as much as I should. I'll try to follow these rules from now on.
Thanks for the reply!
I'm glad the tips were helpful.
Great article.
Thanks!
Very nice! Parceiro.
Obrigado! :)
Great
Thanks!
Great, thanks. I personally would appreciate 2-3 examples for clarification 😊
Nice to know that! I'll share more examples to clarify.
Thanks for your reply.
These are great ideas. Could you consider a post with some solid examples to go with these practices?
Thanks for the feedback.
Yeah! I'm thinking to make a more structured post with these topics, I created this one as a note in my blog and just shared here to see opinions about it.
Thanks!
have a look at gist.github.com/qoomon/5dfcdf8eec6...
Very nice. Thank you!
Good article thanks for sharing these tips.
Thanks! :)
Good ideas. Adding examples will be good to see.
Here are my rules that I stick on to:
Update login button to use the new APIFix #234: User cannot log in with email[WIP] improving the login process[TEMP] add a temporary logout buttonNice tips!
The unique one I try to maintain in the body is the ticket ID because in my case it's just to be tracked in Jira and isn't to be shown.
I absolutely agree to your approach. I've created a highly configurable commit message checker to ensure the right format and valid types and scopes. See github.com/qoomon/git-conventional....
That's really nice, I'll check it.
Thanks for the share.
Great article! Would you mind if I translate this to Spanish in my blog?
I really appreciate that, no problem, just mention the original post. :)