92 lines
4 KiB
YAML
92 lines
4 KiB
YAML
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="http://default/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="http://default/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: { }
|