"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
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/I mean you could make the exact same argument for "when you apply this commit it 'fixes bug 2345'".
Wow it sure is. Sigh
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...
🚀 🚀 🚀
This is the most valuable comment. 👍🏼
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.
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 ✨.
Thanks for sharing
You're Welcome :)
Thanks for 23428! 🤗
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?
What does 23428 signify?
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.
Hey, finally I get instructions on writing good commit messages that goes beyond the "be clear and concise". Thanks!
Thanks for the insights :)
*JajhakAllohu Khoir , Brother. *
🤖🎉🎉