nit: the author proposes "short descriptions" like "fix null pointer exception in payment module" and "refactor data processing pipeline", however "fix" and "refactor" are already in the "type" part of the commit message. Possibly, "payment module" and "data processing pipeline" can (should?) be extracted from the "scope" element. The characters left over after the type and scope can be used smarter.
The Lost Art of Commit Messages
11–20 of 61 posts
Re: The Lost Art of Commit Messages
#12 Reject commit message suggestions
When working on large software projects, commit messages that follow
the format suggested by the author rarely provide additional value.
Having commits prefixed by "chore:" or "docs(ui):" aren't that useful.
Instead, some of those 50 characters can be used for more descriptive
titles. Commit messages are often the best and only context available
when bisecting a bug, so bullet points only really make sense when
making a list. Prose works just fine.
Writing styles vary across contributors but it's much more useful to
get *anything* from someone in their preferred format than nothing at
all because they are frustrated with rules. Some committers do have a
special "committer voice" that they use when describing complex changes
in a commit message. For example, the text here is slightly abridged
and focuses less on the first person than what is typically expected.
This evolves naturally from writing these.
Finally, commit comments definitely should have jokes in them. This is
actually more critical than wrapping them at 72 characters.Re: The Lost Art of Commit Messages
#13I rarely read the commit messages.
It's often faster to just read the code than an obscure description, I'd rather have a small sentence that summarizes what the diff is doing than a technical paper explaining every change in the commit. I don't read pass the title.
Re: The Lost Art of Commit Messages
#14These example commits seem like pretty bad commit messages to me. They are just a summery of the changes (something a motivated reader can rediscover by reading the diff), while leaving out the why, which will be lost to history if not documented.
Re: The Lost Art of Commit Messages
#15--message "wip" Why do we care about commit messages? I only read them when rebasing.
They are incredibly helpful when you are trying to find where a bug was introduced, and trying to figure out why some piece of code is the way it is.
Re: The Lost Art of Commit Messages
#16I prefer:
Using a type is to contrived, because your commit will often include e.g documentation and a feature. Splitting them for the sake of following this pattern makes no sense.
Re: The Lost Art of Commit Messages
#17Do people really gain as much time from being able to read these long messages as they lose in writing them?
I don't think my team would.
Did the author measure this ? If not, he's the monkey.
Re: The Lost Art of Commit Messages
#18Reject commit message suggestions When working on large software projects, commit messages that follow the format suggested by the author rarely provide additional value. Having commits prefixed by "chore:" or "docs(ui):" aren't that useful. Instead, some of those 50 characters can be used for more descriptive titles. Commit messages are often the best and only context available when bisecting a bug, so bullet points…
This isn't prose, it's poetry.
Re: The Lost Art of Commit Messages
#19I rarely read the commit messages. It's often faster to just read the code than an obscure description, I'd rather have a small sentence that summarizes what the diff is doing than a technical paper explaining every change in the commit. I don't read pass the title.
Most of the time that's fine, but then you'll find a bit of code that's broken and the change that added it makes no sense and the commit message is empty. Kind of infuriating.
Re: The Lost Art of Commit Messages
#20You get some of this for free if you create branches and squash merge them when finished. Without needing to think much about commit message, just a few words per commit is enough. This is good enough for me and I don't need to waste any time thinking about it. Example commits of something I worked on a few days back: $ git l feature/character-selection c54825f 3 days ago Robert Schaap (feature/character-selection) S…
Granted, I'm not the target audience of your commit messages, but they tell me very little about what happens. > Add characters I can probably tell from the code that that's what's happening. But what requirements drove these particular characters? > Remove old character What makes it old? How would I recognise an old character in the future? > Show male in editor Why did male not show before? Was there a bug or a pa…
Yeah I think the most important thing to think about when writing a commit message is the intent; a LOT of people use it as a "work log", describing what they did like "removing a character" or "add color picker".
But a commit message needs to describe what the commit does, when applied. A good rule of thumb - also explained on the git site [0] - is to put it in a template like "When applied, this patch will ".
The grandparent comment is almost there though, using the right tense of "fix" instead of "fixed", the latter being in the work log form of "I fixed such and such".
[0] https://git-scm.com/docs/SubmittingPatches/2.2.3#:~:text=Des...