You are a developer, and you started to use Git recently? If you are wondering what the best way to create a good commit message for your project i...
For further actions, you may consider blocking this person and/or reporting abuse
chris.beams.io/posts/git-commit/ details good practices for commit messages
From the above post these 7 rules stand out:
This post is an excellent resource to complete mine! Thank you for sharing it!
I've been encouraging my teams to use Chris' guideline for at least 5 years. It's great in practice and keeps the messaging unified.
I use
git commitwithout -m and it opens up my default editor (Vim),Then the first line defines the title
The second line will define an issue I am working on/fixing if any
The third line will have a well-written description of the commit
Thank you for sharing this. Indeed we can do that. I found the solution with the two "-m" more comfortable to explain. That said, yours is excellent for taking the time to edit the commit! 😃
Yours was well documented and fits so well for beginners. Thank you for taking your time on it.
I find that if it's difficult to describe a change in just the title/subject line (and stick to the character limit), then I am usually committing too much at once and should break it up into smaller commits.
Yes, it is! It's a great practice to do smaller commits.
As I recommend in my post, you can use the following command: "git commit -m 'put a title' -m 'put a description'".
With this, you can write a small title and add details in the description part of the commit.
Hope it helps you! 😊
Valuable for everyone (using git!)
I'm going to review these points before I start my day tomorrow. My coworkers may be thankful that I do.
(Side note) I'm a fan of using
git commit -vto be able to see the code the message I'm writing references.I'm glad it can help you! Thank you! 🙏
(Side note) I didn't know about "git commit -v"!! It's useful if you only use the terminal. I take note of it.
If you want to check your changes before committing, I highly recommend using a tool like Fork.
this is not just a thing for beginners; seems like most devs, all the way along the spectrum just do not care about this. i see so many empty message bodies on commits, with just the title like you showed, one word which says zero about what was done and why.
anyway, good article and thanks for letting me get that off my chest
So true.
At least, if the title is explicit, it's okay. If it's not, a body is useful.
I think it's a good reminder for most developers.
Thank you for your comment! 😉
I personally don't entirely agree with the statement: "Just by reading it, you will be able to remember what you did in this part of your work."
I always repeat that commit messages should be written not to yourself, but for others. A better philosophy would be: "Just by reading it, anyone will be able to clearly understand what you did in this part of your work."
The ability to remember yourself is a natural side-effect of a well-written commit message.
Hello @llcamara ,
You're right! This is what I wanted to mean, but I'm not a native English speaker, maybe it is the reason why I misspoke myself.
When I wrote this guide, it was with the idea of creating a good commit message to mainly improve the collaboration and the productivity (ref: "Why is it essential to write your commit well").
Thank you for your feedback and the proposal!
I update this part of the article right now with your sentence.
Don't get me wrong, I really liked your article and I did understood your points about the importance of collaboration as it went on.
My comment was just a small improvement suggestion, that further reinforces this idea. I'm happy if it helps somehow :)
Don't worry, I didn't take it wrong! 😊
I love receiving feedback from my readers; it's an excellent way to improve the quality of my article.
Anyway, I'm glad you liked the article! Thank you for your help! 😀
I did not know about the double "-m," neat!
I work mostly on personal project (but exported as open source, so I want to maintain a "presentable" look) and I have this habit: I keep two "reference" repositories on two different git providers (typically github and bitbucket). One repository is the official open source rep, the other one is for my own use. When I am working on a specific feature, I create a new branch that I associate with the private rep and use it to save the intermediate states with embarrassing comments like "saving a snapshot."
Whenever I reach a stable, publishable state, I squash the changes in the main branch and publish it on the public rep, this time with a meaningful comment.
If you specify a text editor in your git config, e.g.
editor = /usr/bin/vim
then you can write your commit messages in a more composed way.
Where I work we follow an in-house rule. The first line of the commit message cannot exceed 80 characters, and must begin with the relevant JIRA ticket reference, followed by a space & a pipe character - e.g.:
LRA-4628 | Fixed tests that were broken by front-end change
and then if it needs any further explanation you can put, after a blank line, a short paragraph on what was done. The ticket reference should give you all the info you need, but I find if there was something out of the ordinary found during the change I like to document it in the commit message too.
Some commit messages are just horrible.
Devs must keep following such guidelines to encourage collaboration
I agree with you! I follow some Twitter account about it. They share ugly commit messages, it’s funny, but at the same time, it’s sad for people working on the project 😂.
Guidelines are so important.
You're just gonna mention it and not link to the account?! 😜
Of course, I will share it!! 😁
-> twitter.com/gitlost
I think I should add it to the article 😂👌
So happy it helps you! Thank you for your comment! 🙏