Make all links relative

Now the abs_to_rel module is enabled, links can be made relative so they
work on the current environment.

content/node.1a024983-b73b-4b2c-a350-db9152de27a9.json

@@ -82,9 +82,9 @@
     ],
     "body": [
         {
-            "value": "\n          <p>Yesterday, I <a href=\"https:\/\/twitter.com\/scottkeckwarren\/status\/1594752744165847040\">saw a tweet<\/a> where the writer said they were \u201cfalling into the branch, pull request, and merge after actions pass I use at work even though I'm the only one working on it\u201d.<\/p>\n\n<p>After reading this, my question is, \"Should you, or do you need to, create branches if you're the only person working on a project?\".<\/p>\n\n<p>These days, I use trunk-based development as much as possible, so I hardly ever create new branches, whether working on a project myself or with a team.<\/p>\n\n<p><a href=\"https:\/\/www.oliverdavies.uk\/presentations\/git-flow\">I used to use Git Flow<\/a> and create branches for every new feature and bug fix, but I remember, whilst demonstrating two work-in-progress features to a client, switching between the different branches caused my local site to break. Whilst it wasn\u2019t a major issue, it wouldn't have seemed professional.<\/p>\n\n<p>In a team environment, feature branches are intended to keep different changes and different people's work separate.<\/p>\n\n<p>But is this needed if you\u2019re the only in the team?<\/p>\n\n<p>Assumingly, you're only working on one change at a time, so what's the benefit of creating a separate branch?<\/p>\n\n<p>If you need to switch to a different task, another approach could be to revert your work-in-progress commits, move them onto another local branch temporarily, or wrap them within a feature flag so that the changes are committed but not active.<\/p>\n\n<p>The other part of the tweet said, \u201cI like the little integrations to make sure the tests pass\u201d.<\/p>\n\n<p>I\u2019m comfortable working on a single branch and committing and pushing small changes often.<\/p>\n\n<p>My CI pipelines run for every change that I push, and if one fails, I\u2019ll either push a small fix to get it passing again or revert the failing change and investigate further.<\/p>\n\n<p>For me, working on a single branch keeps my workflow simple and lean, allowing me to focus on the changes and the tasks that I need to work on and not worry about which branch I\u2019m working on.<\/p>\n\n        ",
+            "value": "\n          <p>Yesterday, I <a href=\"https:\/\/twitter.com\/scottkeckwarren\/status\/1594752744165847040\">saw a tweet<\/a> where the writer said they were \u201cfalling into the branch, pull request, and merge after actions pass I use at work even though I'm the only one working on it\u201d.<\/p>\n\n<p>After reading this, my question is, \"Should you, or do you need to, create branches if you're the only person working on a project?\".<\/p>\n\n<p>These days, I use trunk-based development as much as possible, so I hardly ever create new branches, whether working on a project myself or with a team.<\/p>\n\n<p><a href=\"/presentations\/git-flow\">I used to use Git Flow<\/a> and create branches for every new feature and bug fix, but I remember, whilst demonstrating two work-in-progress features to a client, switching between the different branches caused my local site to break. Whilst it wasn\u2019t a major issue, it wouldn't have seemed professional.<\/p>\n\n<p>In a team environment, feature branches are intended to keep different changes and different people's work separate.<\/p>\n\n<p>But is this needed if you\u2019re the only in the team?<\/p>\n\n<p>Assumingly, you're only working on one change at a time, so what's the benefit of creating a separate branch?<\/p>\n\n<p>If you need to switch to a different task, another approach could be to revert your work-in-progress commits, move them onto another local branch temporarily, or wrap them within a feature flag so that the changes are committed but not active.<\/p>\n\n<p>The other part of the tweet said, \u201cI like the little integrations to make sure the tests pass\u201d.<\/p>\n\n<p>I\u2019m comfortable working on a single branch and committing and pushing small changes often.<\/p>\n\n<p>My CI pipelines run for every change that I push, and if one fails, I\u2019ll either push a small fix to get it passing again or revert the failing change and investigate further.<\/p>\n\n<p>For me, working on a single branch keeps my workflow simple and lean, allowing me to focus on the changes and the tasks that I need to work on and not worry about which branch I\u2019m working on.<\/p>\n\n        ",
             "format": "full_html",
-            "processed": "\n          <p>Yesterday, I <a href=\"https:\/\/twitter.com\/scottkeckwarren\/status\/1594752744165847040\">saw a tweet<\/a> where the writer said they were \u201cfalling into the branch, pull request, and merge after actions pass I use at work even though I'm the only one working on it\u201d.<\/p>\n\n<p>After reading this, my question is, \"Should you, or do you need to, create branches if you're the only person working on a project?\".<\/p>\n\n<p>These days, I use trunk-based development as much as possible, so I hardly ever create new branches, whether working on a project myself or with a team.<\/p>\n\n<p><a href=\"https:\/\/www.oliverdavies.uk\/presentations\/git-flow\">I used to use Git Flow<\/a> and create branches for every new feature and bug fix, but I remember, whilst demonstrating two work-in-progress features to a client, switching between the different branches caused my local site to break. Whilst it wasn\u2019t a major issue, it wouldn't have seemed professional.<\/p>\n\n<p>In a team environment, feature branches are intended to keep different changes and different people's work separate.<\/p>\n\n<p>But is this needed if you\u2019re the only in the team?<\/p>\n\n<p>Assumingly, you're only working on one change at a time, so what's the benefit of creating a separate branch?<\/p>\n\n<p>If you need to switch to a different task, another approach could be to revert your work-in-progress commits, move them onto another local branch temporarily, or wrap them within a feature flag so that the changes are committed but not active.<\/p>\n\n<p>The other part of the tweet said, \u201cI like the little integrations to make sure the tests pass\u201d.<\/p>\n\n<p>I\u2019m comfortable working on a single branch and committing and pushing small changes often.<\/p>\n\n<p>My CI pipelines run for every change that I push, and if one fails, I\u2019ll either push a small fix to get it passing again or revert the failing change and investigate further.<\/p>\n\n<p>For me, working on a single branch keeps my workflow simple and lean, allowing me to focus on the changes and the tasks that I need to work on and not worry about which branch I\u2019m working on.<\/p>\n\n        ",
+            "processed": "\n          <p>Yesterday, I <a href=\"https:\/\/twitter.com\/scottkeckwarren\/status\/1594752744165847040\">saw a tweet<\/a> where the writer said they were \u201cfalling into the branch, pull request, and merge after actions pass I use at work even though I'm the only one working on it\u201d.<\/p>\n\n<p>After reading this, my question is, \"Should you, or do you need to, create branches if you're the only person working on a project?\".<\/p>\n\n<p>These days, I use trunk-based development as much as possible, so I hardly ever create new branches, whether working on a project myself or with a team.<\/p>\n\n<p><a href=\"/presentations\/git-flow\">I used to use Git Flow<\/a> and create branches for every new feature and bug fix, but I remember, whilst demonstrating two work-in-progress features to a client, switching between the different branches caused my local site to break. Whilst it wasn\u2019t a major issue, it wouldn't have seemed professional.<\/p>\n\n<p>In a team environment, feature branches are intended to keep different changes and different people's work separate.<\/p>\n\n<p>But is this needed if you\u2019re the only in the team?<\/p>\n\n<p>Assumingly, you're only working on one change at a time, so what's the benefit of creating a separate branch?<\/p>\n\n<p>If you need to switch to a different task, another approach could be to revert your work-in-progress commits, move them onto another local branch temporarily, or wrap them within a feature flag so that the changes are committed but not active.<\/p>\n\n<p>The other part of the tweet said, \u201cI like the little integrations to make sure the tests pass\u201d.<\/p>\n\n<p>I\u2019m comfortable working on a single branch and committing and pushing small changes often.<\/p>\n\n<p>My CI pipelines run for every change that I push, and if one fails, I\u2019ll either push a small fix to get it passing again or revert the failing change and investigate further.<\/p>\n\n<p>For me, working on a single branch keeps my workflow simple and lean, allowing me to focus on the changes and the tasks that I need to work on and not worry about which branch I\u2019m working on.<\/p>\n\n        ",
             "summary": null
         }
     ],