oliverdavies.uk/content/node.53a00f10-a301-4294-ad39-916b9bc2ecd7.yml

uuid:
  - value: 53a00f10-a301-4294-ad39-916b9bc2ecd7
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:07+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: 'Do your commit messages still make sense?'
created:
  - value: '2024-09-03T00:00:00+00:00'
changed:
  - value: '2025-05-11T09:00:07+00:00'
promote:
  - value: false
sticky:
  - value: false
default_langcode:
  - value: true
revision_translation_affected:
  - value: true
path:
  - alias: /daily/2024/09/03/do-your-commit-messages-still-make-sense
    langcode: en
body:
  - value: |
      <p>Once you've <a href="/daily/2024/09/02/no-one-sees-your-clean-up-commits">cleaned up and tided your commits</a>, re-ordered them and squashed any commits together to combine them into logical changes, before you push them, you should also check if your commit messages still make sense.</p>

      <p>Using short or generic commit messages is fine when spiking a solution in very short feedback loops, but when you push your changes, you want them to be as descriptive and meaningful as possible.</p>

      <p>If someone ran <code>git log</code> weeks, months or years from now, would they get value from reading the commit messages?</p>

      <p>Are you using the subject and body correctly and wrapping text when needed?</p>

      <p>Does each message accurately reflect and describe the change?</p>

      <p>Does it capture why the change is needed, any alternative approaches that we considered or tried, or any complications that were encountered?</p>

      <p>If you're following a standard like <a href="/daily/2022/09/01/conventional-commits-changelogs">conventional commits</a>, have you correctly included the required information, such as the type, scope and any references, such as the task reference?</p>

      <p>Having a Git log with detailed history is valuable when you need to review the changes in the future, but it also makes it more likely your changes will be approved and merged, whether you're working on a paid project or volunteering on an open-source project.</p>

              
    format: full_html
    processed: |
      <p>Once you've <a href="/daily/2024/09/02/no-one-sees-your-clean-up-commits">cleaned up and tided your commits</a>, re-ordered them and squashed any commits together to combine them into logical changes, before you push them, you should also check if your commit messages still make sense.</p>

      <p>Using short or generic commit messages is fine when spiking a solution in very short feedback loops, but when you push your changes, you want them to be as descriptive and meaningful as possible.</p>

      <p>If someone ran <code>git log</code> weeks, months or years from now, would they get value from reading the commit messages?</p>

      <p>Are you using the subject and body correctly and wrapping text when needed?</p>

      <p>Does each message accurately reflect and describe the change?</p>

      <p>Does it capture why the change is needed, any alternative approaches that we considered or tried, or any complications that were encountered?</p>

      <p>If you're following a standard like <a href="/daily/2022/09/01/conventional-commits-changelogs">conventional commits</a>, have you correctly included the required information, such as the type, scope and any references, such as the task reference?</p>

      <p>Having a Git log with detailed history is valuable when you need to review the changes in the future, but it also makes it more likely your changes will be approved and merged, whether you're working on a paid project or volunteering on an open-source project.</p>

              
    summary: null
field_daily_email_cta: {  }