Migrate content to YAML

content/node.394246dc-42f8-4fbd-987c-7b62c47b9f06.yml

@@ -0,0 +1,84 @@
+uuid:
+  - value: 394246dc-42f8-4fbd-987c-7b62c47b9f06
+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:55+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: 'Why I like trunk-based development'
+created:
+  - value: '2022-09-20T00:00:00+00:00'
+changed:
+  - value: '2025-05-11T09:00:55+00:00'
+promote:
+  - value: false
+sticky:
+  - value: false
+default_langcode:
+  - value: true
+revision_translation_affected:
+  - value: true
+path:
+  - alias: /daily/2022/09/20/why-like-trunk-based-development
+    langcode: en
+body:
+  - value: |
+      <p>For the majority of my software development career, I've worked with version control in a very similar way.</p>
+
+      <p>There are one or two long-lived branches, usually a combination of <code>develop</code>, <code>master</code> or <code>main</code>, that contain the production version of the code. When starting work on a new feature or bug fix, a new branch is created where the changes are made in isolation, and is submitted for review once complete. This is typically referred to as "Git Flow" or "GitHub Flow".</p>
+
+      <p>Whilst those changes are awaiting review, a new task is started and the process is repeated.</p>
+
+      <h2 id="trunk-based-development">Trunk-based development</h2>
+
+      <p>Something that I've been practicing and advocating for lately is trunk-based development, where there's only one branch that everyone works on, and commits and pushes to instead of creating separate per-task branches.</p>
+
+      <p>Even on a client project where I was the only Developer, I was used to creating per-task branches and I can recall when trying to demo two features to a client and the application broke when switching between branches.</p>
+
+      <p>The vast majority of the time, whether working individually or on a team, I've found that the per-task branches weren't needed and working on a single branch was easier and simpler.</p>
+
+      <p>There are still occassions when a temporary branch is needed, but in general, all changes are made to the single branch.</p>
+
+      <p>Trunk-based development ties in nicely with the continuous integration approach, where everyone commits and pushes their work at least once a day - ideally, multiple times a day. This eliminates long-running feature or bug fix branches that get out of sync with the main branch as well as conflicting with each other.</p>
+
+      <p>It seemed scary to begin with, having been used to per-task branches and asynchronous peer reviews via pull or merge requests, but trunk-based development has made things simpler and encourages other best practices such as pair and mob programming. having a good CI pipeline to identify regressions, using feature flags to separate code deployments from feature releases, and frequent code integration and deployment via continuous commits and pushes.</p>
+
+              
+    format: full_html
+    processed: |
+      <p>For the majority of my software development career, I've worked with version control in a very similar way.</p>
+
+      <p>There are one or two long-lived branches, usually a combination of <code>develop</code>, <code>master</code> or <code>main</code>, that contain the production version of the code. When starting work on a new feature or bug fix, a new branch is created where the changes are made in isolation, and is submitted for review once complete. This is typically referred to as "Git Flow" or "GitHub Flow".</p>
+
+      <p>Whilst those changes are awaiting review, a new task is started and the process is repeated.</p>
+
+      <h2 id="trunk-based-development">Trunk-based development</h2>
+
+      <p>Something that I've been practicing and advocating for lately is trunk-based development, where there's only one branch that everyone works on, and commits and pushes to instead of creating separate per-task branches.</p>
+
+      <p>Even on a client project where I was the only Developer, I was used to creating per-task branches and I can recall when trying to demo two features to a client and the application broke when switching between branches.</p>
+
+      <p>The vast majority of the time, whether working individually or on a team, I've found that the per-task branches weren't needed and working on a single branch was easier and simpler.</p>
+
+      <p>There are still occassions when a temporary branch is needed, but in general, all changes are made to the single branch.</p>
+
+      <p>Trunk-based development ties in nicely with the continuous integration approach, where everyone commits and pushes their work at least once a day - ideally, multiple times a day. This eliminates long-running feature or bug fix branches that get out of sync with the main branch as well as conflicting with each other.</p>
+
+      <p>It seemed scary to begin with, having been used to per-task branches and asynchronous peer reviews via pull or merge requests, but trunk-based development has made things simpler and encourages other best practices such as pair and mob programming. having a good CI pipeline to identify regressions, using feature flags to separate code deployments from feature releases, and frequent code integration and deployment via continuous commits and pushes.</p>
+
+              
+    summary: null
+field_daily_email_cta: {  }