diff --git a/content/meta/index.json b/content/meta/index.json index 943328dfc..ddb18d14c 100644 --- a/content/meta/index.json +++ b/content/meta/index.json @@ -6758,5 +6758,12 @@ ], "node.736063cc-b727-46f4-9a12-3b344d919614": [ "user.b8966985-d4b2-42a7-a319-2e94ccfbb849" + ], + "node.52d92e80-5970-4525-b4b6-b30562f5573c": [ + "user.b8966985-d4b2-42a7-a319-2e94ccfbb849", + "node.c74de3cf-5362-4d08-935a-a9d0d22fcb94" + ], + "path_alias.ceccc753-915b-4361-96d3-44bdbc17bca8": [ + "node.52d92e80-5970-4525-b4b6-b30562f5573c" ] } \ No newline at end of file diff --git a/content/node.52d92e80-5970-4525-b4b6-b30562f5573c.json b/content/node.52d92e80-5970-4525-b4b6-b30562f5573c.json new file mode 100644 index 000000000..3b99cc68c --- /dev/null +++ b/content/node.52d92e80-5970-4525-b4b6-b30562f5573c.json @@ -0,0 +1,98 @@ +{ + "uuid": [ + { + "value": "52d92e80-5970-4525-b4b6-b30562f5573c" + } + ], + "langcode": [ + { + "value": "en" + } + ], + "type": [ + { + "target_id": "daily_email", + "target_type": "node_type", + "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7" + } + ], + "revision_timestamp": [ + { + "value": "2025-07-09T23:07:33+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 type of change are you making?" + } + ], + "created": [ + { + "value": "2025-07-06T23:06:53+00:00" + } + ], + "changed": [ + { + "value": "2025-07-09T23:07:33+00:00" + } + ], + "promote": [ + { + "value": false + } + ], + "sticky": [ + { + "value": false + } + ], + "default_langcode": [ + { + "value": true + } + ], + "revision_translation_affected": [ + { + "value": true + } + ], + "path": [ + { + "alias": "", + "pid": null, + "langcode": "en" + } + ], + "body": [ + { + "value": "Whilst I don't use the [conventional commits][0] approach to writing commit messages any more, I still think it's important to think about the type of change when a commit is made to a code repository.\r\n\r\nAre you adding a new feature?\r\n\r\nAre you fixing a bug?\r\n\r\nAre you refactoring some code?\r\n\r\nConventional commits has you add keywords like `feat`, `fix`, `chore` and `refactor` to the commit message to identify the type of change being committed.\r\n\r\nI don't add it to the commit message, but I do ask myself the same question.\r\n\r\nWhat type of change is this?\r\n\r\nIf it's more than one, it probably needs to be split into separate commits.\r\n\r\nThis makes the intent clearer and the change easier to review.\r\n\r\nIf you need to refactor some code before adding a feature, they should be two separate commits.\r\n\r\nIf you're fixing a bug, commit a failing test first so it can be easily seen and then commit the fix that makes the test pass.\r\n\r\n## Here's the thing\r\n\r\nHaving one change per commit makes it easier to write good commit messages as the change is simpler to explain.\r\n\r\nIf a commit includes multiple changes, it is more difficult and causes commit messages like `Updates` or `wip` - which I try to avoid, especially on client and open source projects.\r\n\r\n[0]: \/daily\/2022\/09\/01\/conventional-commits-changelogs", + "format": "markdown", + "processed": "

Whilst I don't use the conventional commits<\/a> approach to writing commit messages any more, I still think it's important to think about the type of change when a commit is made to a code repository.<\/p>\n

Are you adding a new feature?<\/p>\n

Are you fixing a bug?<\/p>\n

Are you refactoring some code?<\/p>\n

Conventional commits has you add keywords like feat<\/code>, fix<\/code>, chore<\/code> and refactor<\/code> to the commit message to identify the type of change being committed.<\/p>\n

I don't add it to the commit message, but I do ask myself the same question.<\/p>\n

What type of change is this?<\/p>\n

If it's more than one, it probably needs to be split into separate commits.<\/p>\n

This makes the intent clearer and the change easier to review.<\/p>\n

If you need to refactor some code before adding a feature, they should be two separate commits.<\/p>\n

If you're fixing a bug, commit a failing test first so it can be easily seen and then commit the fix that makes the test pass.<\/p>\n

Here's the thing<\/h2>\n

Having one change per commit makes it easier to write good commit messages as the change is simpler to explain.<\/p>\n

If a commit includes multiple changes, it is more difficult and causes commit messages like Updates<\/code> or wip<\/code> - which I try to avoid, especially on client and open source projects.<\/p>\n", + "summary": "" + } + ], + "field_daily_email_cta": [ + { + "target_type": "node", + "target_uuid": "c74de3cf-5362-4d08-935a-a9d0d22fcb94" + } + ] +} \ No newline at end of file diff --git a/content/path_alias.ceccc753-915b-4361-96d3-44bdbc17bca8.json b/content/path_alias.ceccc753-915b-4361-96d3-44bdbc17bca8.json new file mode 100644 index 000000000..f51023b51 --- /dev/null +++ b/content/path_alias.ceccc753-915b-4361-96d3-44bdbc17bca8.json @@ -0,0 +1,27 @@ +{ + "uuid": [ + { + "value": "ceccc753-915b-4361-96d3-44bdbc17bca8" + } + ], + "langcode": [ + { + "value": "en" + } + ], + "path": [ + { + "value": "\/node\/52d92e80-5970-4525-b4b6-b30562f5573c" + } + ], + "alias": [ + { + "value": "\/daily\/2025\/07\/06\/what-type-change-are-you-making" + } + ], + "status": [ + { + "value": true + } + ] +} \ No newline at end of file