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: /daily/2025/07/06/what-type-change-are-you-making
    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.

      Are you adding a new feature?

      Are you fixing a bug?

      Are you refactoring some code?

      Conventional commits has you add keywords like `feat`, `fix`, `chore` and `refactor` to the commit message to identify the type of change being committed.

      I don't add it to the commit message, but I do ask myself the same question.

      What type of change is this?

      If it's more than one, it probably needs to be split into separate commits.

      This makes the intent clearer and the change easier to review.

      If you need to refactor some code before adding a feature, they should be two separate commits.

      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.

      ## Here's the thing

      Having one change per commit makes it easier to write good commit messages as the change is simpler to explain.

      If 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.

      [0]: /daily/2022/09/01/conventional-commits-changelogs
    format: markdown
    processed: |
      <p>Whilst I don't use the <a href="/daily/2022/09/01/conventional-commits-changelogs">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>
      <p>Are you adding a new feature?</p>
      <p>Are you fixing a bug?</p>
      <p>Are you refactoring some code?</p>
      <p>Conventional commits has you add keywords like <code>feat</code>, <code>fix</code>, <code>chore</code> and <code>refactor</code> to the commit message to identify the type of change being committed.</p>
      <p>I don't add it to the commit message, but I do ask myself the same question.</p>
      <p>What type of change is this?</p>
      <p>If it's more than one, it probably needs to be split into separate commits.</p>
      <p>This makes the intent clearer and the change easier to review.</p>
      <p>If you need to refactor some code before adding a feature, they should be two separate commits.</p>
      <p>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>
      <h2>Here's the thing</h2>
      <p>Having one change per commit makes it easier to write good commit messages as the change is simpler to explain.</p>
      <p>If a commit includes multiple changes, it is more difficult and causes commit messages like <code>Updates</code> or <code>wip</code> - which I try to avoid, especially on client and open source projects.</p>
    summary: ''
field_daily_email_cta:
  - target_type: node
    target_uuid: c74de3cf-5362-4d08-935a-a9d0d22fcb94