37 lines
1.6 KiB
Markdown
37 lines
1.6 KiB
Markdown
---
|
|
title: Should you strictly enforce the 50/72 rule?
|
|
date: 2024-05-18
|
|
permalink: daily/2024/05/18/should-you-strictly-enforce-the-5072-rule
|
|
tags:
|
|
- software-development
|
|
- git
|
|
cta: ~
|
|
snippet: |
|
|
Should you strictly enforce the 50/72 rule in your commit messages?
|
|
---
|
|
|
|
[Yesterday], I mentioned the 50/72 rule when writing Git commit messages.
|
|
|
|
The first line in the commit message is the subject line and should be no longer than 50 characters.
|
|
|
|
Any additional lines are the message body and should be wrapped at 72 characters.
|
|
|
|
As I said, I have Neovim configured to format my commit messages based on these rules, although they're more like guidelines.
|
|
|
|
There's no hard limit on the number of characters in the subject line or the number of characters in the body.
|
|
|
|
The commit will work and not be rejected when pushing to your remote repository.
|
|
|
|
There are likely post-commit [Git hooks] to do this, but by default, things will work.
|
|
|
|
A commit message to Drupal core today was 178 characters long, including the issue ID and contributors.
|
|
|
|
When working on project teams, ideally, everyone would follow the 50/72 rule, but if they don't consistently, I don't think it's an issue.
|
|
|
|
I'd rather they focused on writing a good and descriptive commit message and if it's formatted correctly, that's a bonus.
|
|
|
|
Whilst I could automate checks for this, I don't think it's the best use of everyone's time and, especially for Junior Developers who already have enough to learn already, not where their focus should be.
|
|
|
|
[git hooks]: {{site.url}}/daily/2022/08/16/what-are-git-hooks-why-are-they-useful
|
|
[yesterday]: {{site.url}}/daily/2024/05/17/why-i-dont-commit-with--m
|