uuid:
  - value: 78b682e0-a3be-4e49-990b-8fcc7083f6ca
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:00+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: 'Solve one problem at a time'
created:
  - value: '2025-03-01T00:00:00+00:00'
changed:
  - value: '2025-05-11T09:00:00+00:00'
promote:
  - value: false
sticky:
  - value: false
default_langcode:
  - value: true
revision_translation_affected:
  - value: true
path:
  - alias: /daily/2025/03/01/one-problem
    langcode: en
body:
  - value: |
      <p>When using <code>git log</code> to look through the history of codebases, I often see large commits that combine several changes.</p>

      <p>These also lead to vague commit messages like "Changes", "wip" or "Fixes".</p>

      <p>These aren't helpful when reviewing the history and large commits are difficult to review and revert if there is a problem.</p>

      <p>Each commit should be focused on a single change, whether its adding part of a new feature, fixing a bug or refactoring.</p>

      <p>If it's a combination, they should be split into separate commits.</p>

      <p>Each commit should have its own well-written commit message that explains why the change was needed, any consequences or manual deployment steps, alternative approaches that were tried, issues encountered and any follow up actions.</p>

      <p>If you can't properly describe the changes made in a commit, the commit is too big.</p>

      <p>You should uncommit the changes and use <code>git add -p</code> to create a more focused commit.</p>

      <p>This is why <a href="/daily/2024/05/11/don-t-delete-my-commit-messages">I don't squash commits</a>.</p>

      <p>If people have made an effort to create good commits with good commit messages, I don't want them to be lost when the commits are merged.</p>

      <p>I want to keep the history of the changes intact and as it originally was.</p>

      <p>I do sometimes need to <a href="/daily/2025/02/11/tidy">tidy up my own commits</a>, though, before I push them for anyone else to see.</p>

              
    format: full_html
    processed: |
      <p>When using <code>git log</code> to look through the history of codebases, I often see large commits that combine several changes.</p>

      <p>These also lead to vague commit messages like "Changes", "wip" or "Fixes".</p>

      <p>These aren't helpful when reviewing the history and large commits are difficult to review and revert if there is a problem.</p>

      <p>Each commit should be focused on a single change, whether its adding part of a new feature, fixing a bug or refactoring.</p>

      <p>If it's a combination, they should be split into separate commits.</p>

      <p>Each commit should have its own well-written commit message that explains why the change was needed, any consequences or manual deployment steps, alternative approaches that were tried, issues encountered and any follow up actions.</p>

      <p>If you can't properly describe the changes made in a commit, the commit is too big.</p>

      <p>You should uncommit the changes and use <code>git add -p</code> to create a more focused commit.</p>

      <p>This is why <a href="/daily/2024/05/11/don-t-delete-my-commit-messages">I don't squash commits</a>.</p>

      <p>If people have made an effort to create good commits with good commit messages, I don't want them to be lost when the commits are merged.</p>

      <p>I want to keep the history of the changes intact and as it originally was.</p>

      <p>I do sometimes need to <a href="/daily/2025/02/11/tidy">tidy up my own commits</a>, though, before I push them for anyone else to see.</p>

              
    summary: null
field_daily_email_cta: {  }