uuid:
  - value: 42744e61-acab-44e4-bd60-576a30cf7b60
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:02+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: 'What and why'
created:
  - value: '2025-01-24T00:00:00+00:00'
changed:
  - value: '2025-05-11T09:00:02+00:00'
promote:
  - value: false
sticky:
  - value: false
default_langcode:
  - value: true
revision_translation_affected:
  - value: true
path:
  - alias: /daily/2025/01/24/what-why
    langcode: en
body:
  - value: |
      <p>There are two parts to a good commit message.</p>

      <p>The first line summarises the change, but this can be seen by running <code>git diff</code> or <code>git show</code>.</p>

      <p>The subsequent lines should describe why the change was needed, including any additional context, alternative approaches that were considered or tried, follow up steps, issues encountered or anything else that it would be useful to read if someone runs <code>git log</code> or <code>git blame</code> to look at the commit history.</p>

      <p>If there was an issue with this code in the future, what information would be useful to know?</p>

      <p>Why did you take this approach over a different one?</p>

      <p>What error does this commit fix? Include the error message.</p>

      <p>Who requested the change and why? What information can you include that you wouldn't want to lose if you changed your project management or issue tracking software? Don't just link to the issue or add the ticket number.</p>

      <p>What other information and context did you know when you made the commit?</p>

      <p>If anything changes in the future, you can make another commit and repeat the process.</p>

              
    format: full_html
    processed: |
      <p>There are two parts to a good commit message.</p>

      <p>The first line summarises the change, but this can be seen by running <code>git diff</code> or <code>git show</code>.</p>

      <p>The subsequent lines should describe why the change was needed, including any additional context, alternative approaches that were considered or tried, follow up steps, issues encountered or anything else that it would be useful to read if someone runs <code>git log</code> or <code>git blame</code> to look at the commit history.</p>

      <p>If there was an issue with this code in the future, what information would be useful to know?</p>

      <p>Why did you take this approach over a different one?</p>

      <p>What error does this commit fix? Include the error message.</p>

      <p>Who requested the change and why? What information can you include that you wouldn't want to lose if you changed your project management or issue tracking software? Don't just link to the issue or add the ticket number.</p>

      <p>What other information and context did you know when you made the commit?</p>

      <p>If anything changes in the future, you can make another commit and repeat the process.</p>

              
    summary: null
field_daily_email_cta: {  }