42 lines
3.4 KiB
YAML
42 lines
3.4 KiB
YAML
uuid:
|
|
- value: 121756bd-8e3e-4ba4-a0eb-76178deebc60
|
|
langcode:
|
|
- value: en
|
|
type:
|
|
- target_id: daily_email
|
|
target_type: node_type
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
|
revision_timestamp:
|
|
- value: '2025-06-03T22:33:13+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: 'Squashing commits can be OK'
|
|
created:
|
|
- value: '2025-06-02T22:20:11+00:00'
|
|
changed:
|
|
- value: '2025-06-03T22:33:13+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2025/06/02/squashing-commits-can-be-ok
|
|
langcode: en
|
|
body:
|
|
- value: "<p>As well as <a href=\"/daily/2025/04/04/good\">writing good commit messages</a>, I've previously written about <a href=\"/daily/2023/01/25/to-squash-or-not-to-squash\">not squashing commits</a> when merging.</p><p>I think it's beneficial to keep the history of the commits that led to a change, especially if detailed messages have been written for some of the commits.</p><p>Typically, if the commits are squashed as part of a pull or merge request, the history and information is lost or all the messages are merged together - making them hard to read and, arguably, less valuable.</p><p>If you're working in a pair or mob and <a href=\"/daily/2025/06/01/good-commit-messages-dont-always-matter\">creating temporary commits on a short-lived branch</a>, that's a situation when squashing commits is OK - as long as it's done properly.</p><p>I wouldn't have a generic automatically generated message.</p><p>I'd take the time to review the changes on the temporary branch and compare them to the mainline, remove any unrelated changes and write a new commit message that describes all the changes.</p><p>I'd make sure the new message is used and not lost when merged - especially when using online tools.</p><p>Then I can squash any temporary commits and merge the final squashed version.</p>"
|
|
format: basic_html
|
|
processed: "<p>As well as <a href=\"/daily/2025/04/04/good\">writing good commit messages</a>, I've previously written about <a href=\"/daily/2023/01/25/to-squash-or-not-to-squash\">not squashing commits</a> when merging.</p><p>I think it's beneficial to keep the history of the commits that led to a change, especially if detailed messages have been written for some of the commits.</p><p>Typically, if the commits are squashed as part of a pull or merge request, the history and information is lost or all the messages are merged together - making them hard to read and, arguably, less valuable.</p><p>If you're working in a pair or mob and <a href=\"/daily/2025/06/01/good-commit-messages-dont-always-matter\">creating temporary commits on a short-lived branch</a>, that's a situation when squashing commits is OK - as long as it's done properly.</p><p>I wouldn't have a generic automatically generated message.</p><p>I'd take the time to review the changes on the temporary branch and compare them to the mainline, remove any unrelated changes and write a new commit message that describes all the changes.</p><p>I'd make sure the new message is used and not lost when merged - especially when using online tools.</p><p>Then I can squash any temporary commits and merge the final squashed version.</p>"
|
|
summary: ''
|
|
field_daily_email_cta: { }
|