oliverdavies.uk/content/node.d0cabfc7-0a42-4d21-a028-eb1220bfece8.yml

uuid:
  - value: d0cabfc7-0a42-4d21-a028-eb1220bfece8
langcode:
  - value: en
type:
  - target_id: daily_email
    target_type: node_type
    target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
revision_timestamp:
  - value: '2025-05-11T09:00:12+00:00'
revision_uid:
  - target_type: user
    target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
revision_log: {  }
status:
  - value: true
uid:
  - target_type: user
    target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
title:
  - value: 'Should you strictly enforce the 50/72 rule?'
created:
  - value: '2024-05-18T00:00:00+00:00'
changed:
  - value: '2025-05-11T09:00:12+00:00'
promote:
  - value: false
sticky:
  - value: false
default_langcode:
  - value: true
revision_translation_affected:
  - value: true
path:
  - alias: /daily/2024/05/18/should-you-strictly-enforce-the-5072-rule
    langcode: en
body:
  - value: |
      <p><a href="/daily/2024/05/17/why-i-dont-commit-with--m">Yesterday</a>, I mentioned the 50/72 rule when writing Git commit messages.</p>

      <p>The first line in the commit message is the subject line and should be no longer than 50 characters.</p>

      <p>Any additional lines are the message body and should be wrapped at 72 characters.</p>

      <p>As I said, I have Neovim configured to format my commit messages based on these rules, although they're more like guidelines.</p>

      <p>There's no hard limit on the number of characters in the subject line or the number of characters in the body.</p>

      <p>The commit will work and not be rejected when pushing to your remote repository.</p>

      <p>There are likely post-commit <a href="/daily/2022/08/16/what-are-git-hooks-why-are-they-useful">Git hooks</a> to do this, but by default, things will work.</p>

      <p>A commit message to Drupal core today was 178 characters long, including the issue ID and contributors.</p>

      <p>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.</p>

      <p>I'd rather they focused on writing a good and descriptive commit message and if it's formatted correctly, that's a bonus.</p>

      <p>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.</p>

              
    format: full_html
    processed: |
      <p><a href="/daily/2024/05/17/why-i-dont-commit-with--m">Yesterday</a>, I mentioned the 50/72 rule when writing Git commit messages.</p>

      <p>The first line in the commit message is the subject line and should be no longer than 50 characters.</p>

      <p>Any additional lines are the message body and should be wrapped at 72 characters.</p>

      <p>As I said, I have Neovim configured to format my commit messages based on these rules, although they're more like guidelines.</p>

      <p>There's no hard limit on the number of characters in the subject line or the number of characters in the body.</p>

      <p>The commit will work and not be rejected when pushing to your remote repository.</p>

      <p>There are likely post-commit <a href="/daily/2022/08/16/what-are-git-hooks-why-are-they-useful">Git hooks</a> to do this, but by default, things will work.</p>

      <p>A commit message to Drupal core today was 178 characters long, including the issue ID and contributors.</p>

      <p>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.</p>

      <p>I'd rather they focused on writing a good and descriptive commit message and if it's formatted correctly, that's a bonus.</p>

      <p>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.</p>

              
    summary: null
field_daily_email_cta: {  }