"A good commit shows whether a developer is a good collaborator." — Peter Hutterer, Linux.
Years ago, I never realized there were specific rules f...
For further actions, you may consider blocking this person and/or reporting abuse
Great article!! If you are interested in further improving your commit messages, take a look at conventional-commits. It can help you write commit messages in a semantic manner and help in automating a couple of things like release management and changelog generation.
conventionalcommits.org/en/v1.0.0/
github.com/semantic-release/semant...
🚀 🚀 🚀
If you found my content helpful or interesting, and you’d like to show your appreciation, why not buy me a coffee? It’s a small gesture that goes a long way in helping me keep creating more content for you.
Just click the button below to support:
This is the most valuable comment. 👍🏼
If you found my content helpful or interesting, and you’d like to show your appreciation, why not buy me a coffee? It’s a small gesture that goes a long way in helping me keep creating more content for you.
Just click the button below to support:
I might start adding these to all my comments.
Glad to hear that, It’s a small gesture that goes a long way in helping me keep creating more content for you.
Just click the button below to support:
Do Subscribe my YouTube Channel!!! If you all find it helpful as subscription is free but it will motivate me to be active here :)
While I largely agree on Ur points I'm missing why certain things matter, e.g. why the imperative style on commits? I personally prefer the "adds foo ..." Form. Reason: b/c it describes one of many logical step on a topic (branch) which has a goal, that I express then in the imperative, eg "fix bug 2345 scratch that itch"
It is to read like "when you apply this commit it will 'fix bug 2345'". Now if you have any other tense or tone, it'd be weird.
This is a good
copy pastereminder of this article from 2014: cbea.ms/git-commit/Wow it sure is. Sigh
Do Subscribe my YouTube Channel!!! If you all find it helpful as subscription is free but it will motivate me to be active here :)
I mean you could make the exact same argument for "when you apply this commit it 'fixes bug 2345'".
What does 23428 signify?
It signifies no. of ❤️ I got till date .Do Subscribe my YouTube Channel!!! If you all find it helpful as subscription is free but it will motivate me to be active here :)
If you found my content helpful or interesting, and you’d like to show your appreciation, why not buy me a coffee? It’s a small gesture that goes a long way in helping me keep creating more content for you.
Just click the button below to support:
Hey, finally I get instructions on writing good commit messages that goes beyond the "be clear and concise". Thanks!
If you found my content helpful or interesting, and you’d like to show your appreciation, why not buy me a coffee? It’s a small gesture that goes a long way in helping me keep creating more content for you.
Just click the button below to support:
Do Subscribe my YouTube Channel!!! If you all find it helpful as subscription is free but it will motivate me to be active here :)
Thanks for sharing
If you found my content helpful or interesting, and you’d like to show your appreciation, why not buy me a coffee? It’s a small gesture that goes a long way in helping me keep creating more content for you.
Just click the button below to support:
Do Subscribe my YouTube Channel!!! If you all find it helpful as subscription is free but it will motivate me to be active here :)
You're Welcome :)
That is one of the best guides about writing commits I've read. It's so clear and with simple examples, ideal even for begginers like me!
Glad to hear that ❤️ @Thaísa Vieira. Let's connect here linkedin.com/in/safdarali25. Can checkout, here I share awesome stuffs on web and for web ✨.
Not in the title line, at least. If you want to be funny in the body of the commit message, unless you're wasting the reader's time, that's not really a problem.
Personally, I find it distracting to add platform-specific information to your status line. In git terms, #456 means absolutely nothing. Most devs will know that it's some sort of issue number, but that doesn't really help at all when reading the log.
Normally, what you want to see at a glance is: What does this commit do. If you're curious why it does that, you'll read the full commit message anyway. And at that point, it's better to have a full link to the issue so it can be accessed without knowing what issue tracker is being used for the project.
Ideally, you put the explanation of the issue in the commit message; you never know when microsoft might decide to make the issue tracker a premium feature if they're feeling entitled to more of people's hard-earned money.
Overall, I think the subject line should tell you nothing more than what a commit does in a very concise way. Maaaaaybe a short tag like
[fix]or[feat]can be added too for a bit more context, but other than that, the primary rule of thumb is: "Concise status line, have fun with the body".Mentioning issue numbers in commit messages can be very helpful in short-term mid-term, especially in a setup where this will be displayed as a link to an issue or serve as a hint to automatically close the linked issue as resolved.
Yea, but they should ideally only complement a proper description of why a change was necessary, rather than defer entirely to some external system that may or may not be there anymore when someone reads the commit in 5 years.
It also serves that purpose perfectly well in the body of the commit message, so there's no reason to put it in the title line, where people want a concise summary, not a link they first have to click.
I read your article - you can find it on my YouTube channel. I should look into conventional commits.
youtu.be/tnLhwl9hC_A
If you found my content helpful or interesting, and you’d like to show your appreciation, why not buy me a coffee? It’s a small gesture that goes a long way in helping me keep creating more content for you.
Just click the button below to support:
Do Subscribe my YouTube Channel!!! If you all find it helpful as subscription is free but it will motivate me to be active here :)
No thank you, I have no interest in React nor JS.
*JajhakAllohu Khoir , Brother. *
If you found my content helpful or interesting, and you’d like to show your appreciation, why not buy me a coffee? It’s a small gesture that goes a long way in helping me keep creating more content for you.
Just click the button below to support:
Do Subscribe my YouTube Channel!!! If you all find it helpful as subscription is free but it will motivate me to be active here :)
Thanks for the insights :)
If you found my content helpful or interesting, and you’d like to show your appreciation, why not buy me a coffee? It’s a small gesture that goes a long way in helping me keep creating more content for you.
Just click the button below to support:
Do Subscribe my YouTube Channel!!! If you all find it helpful as subscription is free but it will motivate me to be active here :)
Thanks for the insightful perspective. Commit messages are very crucial!
Do Subscribe my YouTube Channel!!! If you all find it helpful as subscription is free but it will motivate me to be active here :)
Thanks for 23428! 🤗
This article looks eerily similar to the following 2014 article at cbea.ms
cbea.ms/git-commit/
If you found my content helpful or interesting, and you’d like to show your appreciation, why not buy me a coffee? It’s a small gesture that goes a long way in helping me keep creating more content for you.
Just click the button below to support:
🤖🎉🎉
Do Subscribe my YouTube Channel!!! If you all find it helpful as subscription is free but it will motivate me to be active here :)
Our application is large, it has a lot of features. When I write a commit message, I often feel like I should specify, which feature this change belongs to. For example, the commit sounds like
Refactor foo_method in Scope::Services::BarProvider(random slightly complicated thing), but from this message it's not clear, what part of application has been affected. I then want to write something likeMessenger: refactor foo_method in Scope::Services::BarProvider. The more correct way would beRefactor foo_method in Scope::Services::BarProvider in Messenger, but it sounds a bit silly. It's probably not a good example, because here theScopemight give an idea about the feature or module, but imagine that it wouldn't.What do you folks do in such situations?
Thanks for the article, but i think you should also include ** conventional commit ** thats a industry standard, which helps to make good release notes out of it.
dev.to/rahulvijayvergiya/git-conve...
Just let github.com/conventional-changelog/... decide if your commit messages match the rules in a pre-commit-hook.