Migrate content to YAML

content/node.aba40c6c-363c-489a-b1d3-b0ac5a5890bf.yml

@@ -0,0 +1,100 @@
+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: {  }