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 API
Fix #234: User cannot log in with email
[WIP] improving the login process
[TEMP] add a temporary logout button
Nice 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. :)
Cool!
I was add "ed" to type word
ex1) Fixed pagination gem bug
ex2) Changed pagination1 gem to pagination2 gem
i think your format is pretty and cool
good to know, I am always curios to know how other people use git commits, isn't your approach (Angular convention)?
-BTW I checked your github, looks that you don't use your idea that much, is there cases where you think it's too much to nail a uniform commits?
Thanks for the reply.
I commonly use the conventional rules, I think it's the same used as the angular convention.
In a repository like my dotfiles I keep in a different way, because I'm not working with a team and organize the commits based in the scopes without types, considering it's just me in the project I make a commits pattern that works for me, but it's very personal.
It was a great article. And it's informative. If you want to do it in gui and add emoji support too. I would recommend this vscode plugin
marketplace.visualstudio.com/items...
I have been using this extension for an year and is awesome.
Thanks for the suggestion!
Some months ago I started using the Emacs + Magit and IMO it's awesome to use together.
Verb tense in commit messages is always a fun one, and each "tense" has a reason (IMO.. comment away but I'm not passionate enough to debate)
Past: What happened to the code, good for merge
Present: Current state of the code, middle-ground for merge/PR
Future: What will happen to the code, good for PR
We like to think:
"Derek was trying to ____________________________."
But our projects are green-field and not toooo crazy.
add the user-card component
adjust loud-voice clamp
add padding to the page-header component
I've created an account to give a like. This comment gave a good laugh; when I read it I initially though that the pattern is literally "Derek was trying to ____________________________."... if you know what I mean. ;)
I have the same feeling here when I read the first time. hahaha
Like he couldn't think of anything?
...but did something regardless.
hahaha
Thanks for the reply and I really enjoy this pattern you talked about.
My name is Derek - and I approve this git message. hahaha
I think we started doing this because / well, we just wanted to be consistent. So - we read somewhere that people use "imperative voice" or something...
But it wouldn't be the first time we decided to do something a certain way and then changed it... so, always looking for "THE BEST" way. ha! Always trying to improve... but we can lazy-load it.