71–80 of 99 posts
Earlier quoted context omitted.
Of course not. How else would you do it?
Make a human read the commit history (or tickets) and summarize changes in the language useful for users, not for developers.
Earlier quoted context omitted.
I agree that full sentences (e.g. like Email subjects or blog post titles) are better. Tagging commits with feature/bug/etc is not particularly useful, as more often than not the line between feature, bug, etc is blurry. At times it can also be unclear what tag to use, leading to arbitrary choices. For example: is a performance improvement a feature, or a bug fix? The tags also add no value when reading commit messag…
> feature/bug/etc is not particularly useful It's useful for automatically determining the next semantic release version by inspecting the commit history alone. fix: feat: breaking: <-- major
Earlier quoted context omitted.
> the usual 50 character limit. People do this? I guess it's fine if your commits are Personally, almost all my commits follow email styling: first line tries to be concise, newline, then a list of what changes have been made along with a brief justification. Feels like a bare minimum unless you'd rather tie everything into pr's (which can't be seen from command line). This is why for people unfamiliar with git I ref…
You're arguing against a strawman because you misunderstood the parent comment. The character limit was only referring to the subject line. Under it you can have as many lines of additional context as you wish. That's the normal way; the subject is brief, the message is arbitrarily long. For what it's worth, the linux kernel limits it to around 70 chars and uses a subsystem prefix, so clearly that can work on large l…
Earlier quoted context omitted.
> Why? The machine-readable part is useful for generating changelogs (eg. broken out by type) or implementing semver (eg. detecting breaking changes).
but isn't it an antipattern to generate change-logs from commit subject lines?
Earlier quoted context omitted.
> Why? The machine-readable part is useful for generating changelogs (eg. broken out by type) or implementing semver (eg. detecting breaking changes).
but isn't it an antipattern to generate change-logs from commit subject lines?
I’ve found the commit message guidelines at https://git-scm.com/book/en/v2/Distributed-Git-Contributing-... to very helpful for clarity. “ The last thing to keep in mind is the commit message. Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. As a general rule, your messages should start with a single line that’s no more than about 50 characters and that des…
Earlier quoted context omitted.
50 chars seems pretty arbitrary to me. I'd rather have a useful commit message. I've seen some pretty contorted messages conveying no real info in order to meet an imaginary character limit.
the 50 chars is for the subject. the commit message (body) has no character limit (apart from a character limit per line).
Earlier quoted context omitted.
but isn't it an antipattern to generate change-logs from commit subject lines?
That all depends on what you do with the meta-data in the commits. For example, at my work, we analyze the history at the level of merges, not commits, and that works pretty well for us.