However, not on board with the hate for rebase. If it's your feature branch and you aren't sharing it with others, I'd much rather get a cleaned up PR than one filled with junk commits because the author was afraid to rebase.
But in general I liked the article. It's under-appreciated how helpful a good commit log is.
No: it's supposed to be written in imperative form. For those of us who are not linguists, it's easiest to explain this as a continuation of that phrase. However, it isn't a continuation. It stands on its own.
Sometimes commit message deserves to be moderately long, like a paragraph or more. If one did not reference a code review or issue tracker link, for example, the need would likely be common. Even with an issue tracker there's value in capturing a few sentences of detail and sometimes more in the commit.
By capitalizing the commit message, it is natural to extend it from a single sentence phrase to a paragraph with an introductory sentence. I think of commit messages as analogous to JavaDoc where the first sentence or first line is taken as the subject, or like a document with a heading. It would be silly for short commit messages not to use capitalization while long do. A capitalized message works as a short description of the intro to a paragraph. Generally. once you're writing more than a single standalone sentence, capitalize. In a permanent medium where it can be either one, also capitalize.
A capitalized sentence or sentence fragment works in many contexts, like within a document or email. It would be annoying to convert going back and forth. Lastly, commit messages can sometimes act as names or proper nouns, and capitalization reinforces that role. Capitalization looks better as project or item headers in an issue tracker, and so to the extent that commits follow items, it's nice to consistently capitalize.
Capitalize commit messages because when Git tools generate commit messages, they generate capitalized ones. (Be consistent.)
I grok not capitalizing IM or IRC or other chat conversations, though I do if I start writing messages longer than a sentence. For everything but IM, capitalization constitutes the norm and good professional style.
This rationale might not be entirely satisfying, because why does English have capitalization to begin with? That's a linguistic question I don't know the answer to. However, I do know that the norms that lead to sentence capitalization also apply to commit messages and code documentation Not capitalizing them feels like refusing to capitalize any other writing: a potential distraction from the content.
foo: Add utf8 support
# If applied, this commit will...
# Explain why this change is being made
# Provide links to any relevant tickets, articles or other resourcesIn particular, it looks like this:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
I like it because I find that adhering to this style lets me have a nice seat of easy to read commits which explain their purpose and scope clearly.
Also, it lets me use a tool like `clog-cli` [1] to generate pretty changelogs [2] automatically!
The only nitpick I have with this style is the fact that they recommend not capitalizing the first letter of the subject line. This means that, for example, in emails or when creating a PR, I have to capitalize the summary so that it looks correct. Minor, but annoying.
[0]: https://github.com/conventional-changelog/conventional-chang...
[1]: https://github.com/clog-tool/clog-cli
[2]: https://github.com/clog-tool/clog-cli/blob/master/changelog....
I can't recall where now, but I remember reading (and agreeing with) an article which proposed a slightly different format - describe what the commit did. "Fixes the js typo on the foo page".
Grammatically, I prefer this method as well, since the commit has already been applied, so it's not "going" to do anything; it's already been done.
Of course, the only difference is in the tense of the leading verb, so it's probably one of those "potato" thing.
Ain't English fun?
If it's telling me what to do, that doesn't make any sense either, since the work's already been done; the results of doing that work is the commit.
I guess it could be considered to be an abstraction of what request initiated the change, but what value does that provide when going back through git logs (when compared to a past or present verb tense that describes the changes)?