This myth comes from the era of 80-column x 25-line text terminals. Here’s Why You Should Write Longer Commit Messages

Remember when Twitter was a platform where you could only post up to 140 characters at a time – the maximum allowed in an SMS text message?

Since 2017, Twitter has allowed 280 characters — about 40 to 70 words or something you can read in about 15 seconds — in a message.

But for some reason, GitHub still promotes the myth that “the great commit summary is only 50 characters” – to the point of saying that when you use GitHub Desktop or the online GitHub editor to code.

A 50-character git commit message is useless. Seriously, the “50-character rule” is a giant, silly myth that we need to move on. Here’s how it got started.

This widespread myth comes from the day when git was purely a command line tool, and terminals were max 80 characters wide,

While many developers still prefer the command line gitOf course, I spend 99% of my time doing git messages in a GUI, usually GitHub Desktop, and viewing them online. It’s easier.

Now, as many terminals as-many-characters-wide-you want, many developers use ultra-high-definition (“Retina”) displays at work.

Let’s debunk the myth of the 50-character commitment once and for all. By the end of this article, you will be writing the best commit messages of your life.

Let’s compare 50-character summaries. Here is a git commit message truncated to 50 characters. The message is fine, but it is not very informative:

chore: upgrade the apollo client to the new versio

But what if we don’t worry about the length of the git commit message and instead add some additional information? I put ... At 50 characters:

chore: upgrade the apollo client to version 3.6.8 ... (latest) from 2.6.8, fixing the imports and use of `inMemoryCache`

And what if we add some useful information for the next developer (myself or someone else) in the expanded description field?

chore!: upgrade the apollo client to version 3.6.8 ... (latest) from 2.6.8, fixing the imports and use of `inMemoryCache`BREAKING CHANGE: There are multiple breaking changes in v3.0.0 of @apollo/client. See the upgrade guide at: https://github.com/apollographql/apollo-client/releases/tag/v3.0.0

But what about viewing the commit summary on GitHub? You will be able to see the first 70 characters in the log, and you can click ... To see the rest:

chore!: upgrade the apollo client to version 3.6.8 (latest) from 2.6.8 ..., fixing the imports and use of `inMemoryCache`BREAKING CHANGE: There are multiple breaking changes in v3.0.0 of @apollo/client. See the upgrade guide at: https://github.com/apollographql/apollo-client/releases/tag/v3.0.0

The myth persists because if you look at commit summaries on GitHub, they are limited (for no apparent reason) to 70 characters.

But it requires only one click ... To expand the commit message to see the summary and full details.

Even better, you can use git log command. here is git log The command is automatically ready to run on the command line:

git log origin..HEAD --reverse --format="✅ %s%n%b %N%n" > git-log.txt && code git-log.txt

And here’s the version that a . ready to put in package.json file for use with npm run either yarn, i like to use yarn gitlog When I open a PR.

"gitlog": "git log origin..HEAD --reverse --format=\"✅ %s%n%b %N%n\" > git-log.txt && code git-log.txt",

This command gives you a list ready to copy-paste in a pull request (PR) of all the commits you have done in the current working branch.

Each commit is labeled with a and lists the summary (full-length, not just 50 characters) followed by the description (if any) on a new line.

This means that you can write a “normal” commit message of 100 characters (14-25 words) or as long as you like, and it will still display different from what you included.

The way I’ve been using it is to include documentation or links to a code block (formatted in markdown, with ``` before and after on a new line) in the description.

Then, when I open the PR, I have a complete “git log” in a much better format in the summary section of the PR, rather than the commit section.

The only downside I’ve run into is that I have to edit the PR summary message if I add additional work. However, this always has a downside to adding code after opening a PR – new commits are relatively hidden in the workflow.

Compare the following commit to how GitHub recommends (50 characters) and how I wrote it. Here are the 50-character versions:

chore: remove the @Docusaurus ESLint plugin as we

As you can see, I’m still using a “semantic commit” message (a “homework” that doesn’t touch any user-facing code or features), but it sucks.

I am professional With 20 years work experience (so you can call me a senior Developer), so here’s what I actually wrote:

chore: remove the @Docusaurus ESLint plugin as we don't support translations of the docs at this timeThere are only 2 supported rules in the @docusuarus ESLint plugin, and they're only useful for i18n (translations).Reference:
https://docusaurus.io/docs/api/misc/@docusaurus/eslint-plugin#supported-rules

What should I write as a commit message if I don’t write a reasonably descriptive commit summary (in this case, about 100 characters)? Here are two examples where I tried to force the commit message to 50 characters:

chore: rm @Docusaurus ESLint plugin as no i18n now

Does it matter at all to anyone? The “great commit message” (as GitHub would put it) is written in vaguely technical jargon, uses two abbreviations, and makes no reference to what I’m doing. what about this one?

chore: remove @Docusaurus ESLint plugin no transla

I hope you can see my point. Here I actually wrote the commit message as a summary, and no, it didn’t take longer than the above.

chore: remove the @Docusaurus ESLint plugin as we don't support translations of the docs at this time

Wow, that commitment is understandable! I can still read it in under five seconds—but better than that, I can actually understand it in less than five seconds.

Now, let’s take a screenshot of how yarn gitlog The command I described earlier turned out to be this commit:

We can complain about our formatting – maybe I can add a blank space between the commit message and description for maximum readability – but nobody needs to click ... Like the previous screenshot, which showed the “commit” section of the PR on GitHub.

To get things done, the biggest disadvantage of encouraging small commitments is that most people will take the easy route because shorter === better,

We shortened the nice, readable commit message we saw above, including an exact link to the correct part of the docs in the summary.

How many times have we worked with super-talented developers who write the world’s worst commit messages? Many PRs contain messages such as:

fix the thingrefactorit seems like it's working

By GitHub’s standard, they’re all “great commit messages”: 50 characters or less, so they’ll fit in an old-school 80-column terminal.

Even when commit messages are semantic (traditional commit), some developers are in the habit of not giving any additional information:

chore: remove Docusaurus ESLint pluginchore: remove unused packageschore: restore ESLint rule I removed

Do any of those commit messages tell you anything? The original developer may remember what they were working on, at least for a few weeks, or you can dig it out from the commit history with a code comparison.

I don’t know about you, but I have better things to do than code (check the notes) to compare, not even a PR, but a personal commitment.

are you serious? You seriously expect I’m going to code, compare your commit because you were lazy?

Look, I understand the impulse that “A short summary is more readable,” “Remove unnecessary words,” And “The earnest Hemingway did it!”

But the reality is that the whole point of makingnuclear commit“(Where you only change one thing at a time) so you can figure out what you did later and reverse it or patch it as needed. This requires context.

And you won’t find context just from GitHub’s commit screen when reviewing a PR, especially if the developers insist on only writing “great” commit messages with less than 50 characters. This is bad practice.

Issue based on PR’s commit section of GitHub, and not using any yarn gitlog The command is that you can’t tell if GitHub’s ... This means that the commit message was too long or that the description contained five paragraphs.

so i always use yarn gitlogcommand – you can access the commit history very easy without having to click in the summary of the PR ... To expand every commit on the Commits screen.

Also you can customize git log Order for your own needs to make it more useful for you and your team. If you need additional information, such as authorship or dates, you can simply update it. yarn gitlog script.

Hope I have convinced you to write more than 50 characters in your git commit message. But, if I haven’t, then go traditional commits.org — Most of his “best practice” examples are >50 characters long!

feat!(api): introduced concept of writing more than 50 charactersBREAKING CHANGE: don't believe every `ProTip!` you read at GitHub

Happy coding! I