uuid:
  - value: aba40c6c-363c-489a-b1d3-b0ac5a5890bf
langcode:
  - value: en
type:
  - target_id: daily_email
    target_type: node_type
    target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
revision_timestamp:
  - value: '2025-05-11T08:59:58+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: 'Writing good commit messages'
created:
  - value: '2025-04-04T00:00:00+00:00'
changed:
  - value: '2025-05-11T08:59:58+00:00'
promote:
  - value: false
sticky:
  - value: false
default_langcode:
  - value: true
revision_translation_affected:
  - value: true
path:
  - alias: /daily/2025/04/04/good
    langcode: en
body:
  - value: |
      <p>There are many good resources and interesting articles online about how to write good messages when committing changes to a Git repository.</p>

      <p>The post I often refer to is <a href="https://cbea.ms/git-commit">How to Write a Git Commit Message</a> by Chris Beams.</p>

      <p>In his post, he explains why good commit messages matter and gives these seven rules:</p>

      <blockquote>
        <ul>
        <li>Separate the subject from body with a blank line.</li>
        <li>Limit the subject line to 50 characters.</li>
        <li>Capitalize the subject line.</li>
        <li>Do not end the subject line with a period.</li>
        <li>Use the imperative mood in the subject line.</li>
        <li>Wrap the body at 72 characters.</li>
        <li>Use the body to explain what and why vs. how.</li>
        </ul>
      </blockquote>

      <p>I'd recommend reading the article to get the full context.</p>

      <p>Rules two and six suggest lengths for the subject line and body which is another reason <a href="/daily/2025/04/02/commit">why I rarely use <code>-m</code></a> when committing changes.</p>

      <p>Whilst you can create multi-line commit messages on the command line, by opening it in my preferred editor (Neovim for me), I can see where the lines should end and be warned if I exceed them.</p>

      <p>I can even include Chris' rules in my commit message template so I see them whenever I'm about to commit something.</p>

      <p>This additional feedback helps me create my commit messages how I intend.</p>

              
    format: full_html
    processed: |
      <p>There are many good resources and interesting articles online about how to write good messages when committing changes to a Git repository.</p>

      <p>The post I often refer to is <a href="https://cbea.ms/git-commit">How to Write a Git Commit Message</a> by Chris Beams.</p>

      <p>In his post, he explains why good commit messages matter and gives these seven rules:</p>

      <blockquote>
        <ul>
        <li>Separate the subject from body with a blank line.</li>
        <li>Limit the subject line to 50 characters.</li>
        <li>Capitalize the subject line.</li>
        <li>Do not end the subject line with a period.</li>
        <li>Use the imperative mood in the subject line.</li>
        <li>Wrap the body at 72 characters.</li>
        <li>Use the body to explain what and why vs. how.</li>
        </ul>
      </blockquote>

      <p>I'd recommend reading the article to get the full context.</p>

      <p>Rules two and six suggest lengths for the subject line and body which is another reason <a href="http://default/daily/2025/04/02/commit">why I rarely use <code>-m</code></a> when committing changes.</p>

      <p>Whilst you can create multi-line commit messages on the command line, by opening it in my preferred editor (Neovim for me), I can see where the lines should end and be warned if I exceed them.</p>

      <p>I can even include Chris' rules in my commit message template so I see them whenever I'm about to commit something.</p>

      <p>This additional feedback helps me create my commit messages how I intend.</p>

              
    summary: null
field_daily_email_cta: {  }