A commit message is a short description of the changes you've made to a file added before committing the changes.
Good commit messages are important not only for others who you may be collaborating on the project but also for you, to keep track of all your commits and knowing exactly what changes where maybe during that particular commit.
Even if you're working on a personal project, I'd recommend that you start getting in the habit of writing good commit messages.
This is the format that I use most of the time (this may change depending on your preference or organization your working for):
type: subject
body (optional)
footer (optional)
1. Type
- feat - a new feature
- fix - a bug fix
- docs - changes in documentation
- style - everything related to styling
- refactor - code changes that neither fixes a bug or adds a feature
- test - everything related to testing
- chore - updating build tasks, package manager configs, etc
2. Subject
This contains a short description of the changes made. It shouldn't be greater than 50 characters, should begin with a capital letter and written in the imperative eg. Add instead of Added or Adds.
3. Body
The body is used to explain what changes you made and why you made them. Not all commits are complex enough that they need a body, especially if you are working on a personal project alone, and as such writing a body is optional.
A blank line between the body and the subject is required and each line should have no more than 72 characters.
4. Footer
The footer is also optional and mainly used when you are using an issue tracker to reference the issue ID.
Example of a good commit message used by Udacity student Udacity Git Commit Message Style Guide
feat: Summarize changes in around 50 characters or less
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 the commit 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); various tools likelog,shortlog
andrebasecan get confused if you run the two together.Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain to them.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 hereIf you use an issue tracker, put references to them at the bottom,
like this:Resolves: #123
See also: #456, #789
A more practical example:
docs: Fix typo in README.md
Oldest comments (70)
Thanks, helpfull
You're welcome :)
Short and clear, thank you for this article!
I tend to use emojis for the type - it shows the type of the commit at first glance, e.g.:
โ
:heavy_plus_sign:when adding a file or implementing a feature๐จ
:hammer:when fixing a bug or issue๐
:green_heart:when improving code or commentsโก
:zap:when improving performance๐
:scroll:when updating docs or readme๐
:key:when dealing with security๐
:repeat:when updating dependencies or dataโ
:white_check_mark:when a new release was built๐
:shirt:when refactoring or removing linter warningsโ
:x:when removing code or files... and looks awesome in the commit history:
Thanks for your tip!
Here is the web for other Git emoji ideas: gitmoji.carloscuesta.me/
For me, it looks too much to remember,
so I just use some emojis to keep it simple:
๐
:tada:initial commit ๐๐
:rocket:[Add] when implementing a new feature๐จ
:hammer:[Fix] when fixing a bug or issue๐จ
:art:[Refactor] when refactor/improving code๐ง
:construction:[WIP]๐
:pencil:[Minor] Some small updatesMy pleasure ๐
This is also a nice interpretation, in the end it's a matter of taste, I think.
It is too much to remember. I use github.com/carloscuesta/gitmoji-cli so that I don't have to remember which emoji is used for which type. It's a git commit hook, so I just do
git commit, and it interactively helps me pick the appropriate emoji, write my commit message, and then drops it into my editor to make changes as needed.If you must use an additional tool to remember your emoji meaning, I bet other too are lost for the interpretation of the emoji, once the wow effect has passed, I think words are much easier and quicker to understand :)
I almost always use both: emoji for recognizing the commit type at first glance and text for a clear and unambiguous description ๐๐ป
yes but even for the commit type, I find a word more meaningful than an emoji (and new people on the project / people reading commits without being part of the project) don't need to learn what emoji corresponds to what :).
You make using emojis sound like rocket science ๐ we're talking about little pictures with clear content. A hammer is for fixing something, a scroll is for something documentation related. There really isn't much to learn ๐คทโโ๏ธ
I've seen emojis being used in some projects but they always seemed intimidating to me, I'll have to look more into how to use them
It needs a little time to getting used to it, but then you don't want to be without it anymore, I promise ๐
I never thought to use emojis for that LOL. THIS'LL HELP ME A LOT. ๐คฉ
Glad I could help ๐
Wow, it looks so awesome.
Tnx for sharing your tips :)
My pleasure ๐
I think it would be better to write a complete post about the way you are using Emojis!
Keep it up ;)
Thank you for this suggestion and the encouragement - I'll draft this to my list of post ideas ๐๐ป
Nice to hear that you found my suggestion cool.
I'm waiting for your amazing post.
Keep Moving Forward ใ
Code with ๐
๐ ๐ ๐ ๐ ๐
I hate when people do stuff like this. It just looks confusing in the
git log. Just use unicode emojis instead, they work everywhere.BTW my favourite emojis for commit messages: ๐๐๐๐๐ข๐ (I usually put them at the end of the commit message though)
Thank you for this valuable addition. Most of the terminals / bash / consoles support way more than unicode emojis nowadays. So that shouldn't be a problem for most of us. Here is, what my
git loglooks like:Unicode emojis are standardized though, while the
::notation is not.I ALWAYS forget that emojis are valid in all kinds of spaces now. I often use them in debug console messages to make it visual and easy to search, but using them in this git commit message format is super handy. Thanks for the recommendation!
You're very welcome, I'm glad it's useful for you ๐
use this gitmoji.carloscuesta.me/
I LOVE THIS. I might even print it out and stick on my wall. Thankyou!
You're welcome ๐
Looks so cool.
Thank You ๐
Thank a lot!
That's exactly what I need these days!
This is so helpful - I'm terrible with commit messages and have not made it a priority to figure out a consistent method on what to write. Appreciate this sort of formula you have created!
I didn't create it myself by the way, but you're welcome ๐
I wish my commits were that good, I did adopt this style a while back, also tried the gitmoji style for a while but, then I reverted back to simple -
Add, Create, Remove, Deletetitles. ๐Might try this style of commits again, I really like how they look and the organization of them just feels better to me, also seems better for filtering with the colon as a separator. ๐ฅ
This is just one way to do it if you have no problem understanding your commits with the way you've been using then continue using that as long as it's clear and people won't have any trouble understanding the message.
Nice article!
I always try to follow these two guides:
chris.beams.io/posts/git-commit/
conventionalcommits.org/en/v1.0.0/
I use gitmoji.carloscuesta.me/
And I switch the footer and body, putting this issue system at higher importance.
Git is a Communication tool
Jesse Phillips ใป Dec 12 '18 ใป 2 min read
Thank you, short and very clear.
I also use that, I avoid writing a body at all cost but I just wanted to put it out there just so people can know that it's an option ๐
Exactly what I experienced ๐๐ป