85 lines
3.9 KiB
YAML
85 lines
3.9 KiB
YAML
uuid:
|
|
- value: 46f8d4ae-3203-4b91-9bd3-13e0b8ad240d
|
|
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:26+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: |
|
|
Are conventional commits worth it?
|
|
created:
|
|
- value: '2023-11-24T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:26+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2023/11/24/are-conventional-commits-worth-it
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>For some time, I've written commit messages following the Conventional Commits specification, where you start the subject with the type of commit - such as <code>feat</code>, <code>fix</code>, <code>chore</code>, <code>docs</code>, etc - and provide an optional scope before completing the subject line (the first line in the message).</p>
|
|
|
|
<p>Then, it is encouraged to add a longer body to the message and provide any links and task IDs that the change relates to.</p>
|
|
|
|
<p>Now I've been using it for a while, I'm deciding whether it adds value for me and whether it's worth me using it.</p>
|
|
|
|
<p>I don't create automatic CHANGELOG files from the commit types.</p>
|
|
|
|
<p>The scopes are usually arbitrary, it's unclear which scope (or scopes) should be added, or it repeats the module name I'm working on (which I could see from the Git diff).</p>
|
|
|
|
<p>While I see value in writing descriptive commit messages, I'm unsure if I do to format the subject line in this way.</p>
|
|
|
|
<h2 id="here%27s-the-thing">Here's the thing</h2>
|
|
|
|
<p>I like to use an iterative approach to my workflow. I like to try things and see if they work for me. If not, I can stop or continue iterating.</p>
|
|
|
|
<p>If working with others, should you focus on writing commits that categorise commit messages within their subject or writing descriptive commit messages that capture why the change is needed?</p>
|
|
|
|
<p>Which provides the most value when looking back at the Git log in the future?</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>For some time, I've written commit messages following the Conventional Commits specification, where you start the subject with the type of commit - such as <code>feat</code>, <code>fix</code>, <code>chore</code>, <code>docs</code>, etc - and provide an optional scope before completing the subject line (the first line in the message).</p>
|
|
|
|
<p>Then, it is encouraged to add a longer body to the message and provide any links and task IDs that the change relates to.</p>
|
|
|
|
<p>Now I've been using it for a while, I'm deciding whether it adds value for me and whether it's worth me using it.</p>
|
|
|
|
<p>I don't create automatic CHANGELOG files from the commit types.</p>
|
|
|
|
<p>The scopes are usually arbitrary, it's unclear which scope (or scopes) should be added, or it repeats the module name I'm working on (which I could see from the Git diff).</p>
|
|
|
|
<p>While I see value in writing descriptive commit messages, I'm unsure if I do to format the subject line in this way.</p>
|
|
|
|
<h2 id="here%27s-the-thing">Here's the thing</h2>
|
|
|
|
<p>I like to use an iterative approach to my workflow. I like to try things and see if they work for me. If not, I can stop or continue iterating.</p>
|
|
|
|
<p>If working with others, should you focus on writing commits that categorise commit messages within their subject or writing descriptive commit messages that capture why the change is needed?</p>
|
|
|
|
<p>Which provides the most value when looking back at the Git log in the future?</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|