{ "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": "\n

When using git log<\/code> to look through the history of codebases, I often see large commits that combine several changes.<\/p>\n\n

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

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

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

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

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>\n\n

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

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

This is why I don't squash commits<\/a>.<\/p>\n\n

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>\n\n

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

I do sometimes need to tidy up my own commits<\/a>, though, before I push them for anyone else to see.<\/p>\n\n ", "format": "full_html", "processed": "\n

When using git log<\/code> to look through the history of codebases, I often see large commits that combine several changes.<\/p>\n\n

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

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

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

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

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>\n\n

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

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

This is why I don't squash commits<\/a>.<\/p>\n\n

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>\n\n

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

I do sometimes need to tidy up my own commits<\/a>, though, before I push them for anyone else to see.<\/p>\n\n ", "summary": null } ] }