mirror of
https://github.com/conventional-commits/conventionalcommits.org.git
synced 2026-03-22 12:44:37 -05:00
Clarification on 50 char rule #140
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/conventionalcommits.org#140
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @xsrvmy on GitHub (Feb 13, 2022).
There is typically a recommendation that the summary message for a commit should not exceed 50 chars. Does this still apply for conventional commits, or should the counting only include the content after the colon? This is especially relevant if the
feat(...)syntax is used.@damianopetrungaro commented on GitHub (Feb 14, 2022):
@xsrvmy including the
type(scope)because most of the platform will trim commit messages around that number.@dsbert commented on GitHub (May 13, 2022):
It's already difficult to fit the summary into 50 characters. With this convention, you are down to ~40 before you even start the summary. It would be great to have some recommendation in the FAQ, if not the spec, that I can point my team to.
@damianopetrungaro commented on GitHub (May 13, 2022):
Hey @dsbert thanks for the comment.
It is important to know that the first line needs to be ~50chars otherwise most of the code hosting platforms (GitHub, Gitlab, etc...) will trim the description, adding some
...at the end, and when reading the git history you won't be able to understand the purpose of a commit message without clicking it and then read the whole content.Keep also in mind that you can add a very long description after the first line, meaning that the body and the footer do not have a suggested length.
@Conaclos commented on GitHub (Aug 3, 2022):
In my experience the 50 chars rule is hard to follow. The limit should not be strictly enforced. For instance commit titles of the Linux kernel are in average around 50 chars and most are under the 70-75 chars (this is a soft limit proposed by developers of the Linux Kernel)
72 chars is more easy to follow than 50 chars. This is the actual limit of tools like GitHub before to add
....@xsrvmy commented on GitHub (Aug 3, 2022):
I think the 50 char issue is specifically for command line tools like git log. IDK if GitHub uses character count or width with css ellipsis.
@Conaclos commented on GitHub (Aug 3, 2022):
I could even think it is related to git patch/mail workflows: the commit title is used as mail's subject and is generally prefixed with
[PATCH x/y].@damianopetrungaro commented on GitHub (Sep 7, 2022):
Also, keep in mind that the 50 char rule is not mandatory, and conventional commits do not specify it.
If you feel to add more chars to your message you are free to do that; just consider that some users won't be able to read the full commit message when navigating a UI of a website/tool.
Closing this, feel free to reopen if any of you (or others) do have other questions about it!
@TristanCottam commented on GitHub (Apr 15, 2023):
Even if the 50-character rule isn't part of the Conventional Commits specification, I feel like it should at least mention its existence, its reason, and why it isn't adopted. Same goes for the 72-character rule for the commit body. However, I think the specification should at least set a soft limit on the commit's description and body.
I've heard both those numbers so many times I naively thought they were universally accepted by all modern standards. I can't imagine I'm the only one.
EDIT: See #518.