76 lines
3.6 KiB
YAML
76 lines
3.6 KiB
YAML
uuid:
|
|
- value: 7fe749a2-90b7-4d22-9dff-56eaa7adb3d5
|
|
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:12+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: "Why I don't commit with -m"
|
|
created:
|
|
- value: '2024-05-17T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:12+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2024/05/17/why-i-dont-commit-with--m
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>A lot of tutorials show using <code>git commit -m</code> to create commits using an inline message.</p>
|
|
|
|
<p>I don't do that, though.</p>
|
|
|
|
<p>Using the <code>-m</code> option to specify an inline commit message encourages writing short one-line commit messages instead of using the subject and body effectively to document more about the change, such as why it was needed, any other approaches taken and the consequences of the change within the commit.</p>
|
|
|
|
<p>Alternatively, people could write a longer commit message in one line and not follow the 50 character limit for the subject line.</p>
|
|
|
|
<p>Whilst it's possible to write multi-line commits on the command-line, I use my editor (Neovim) to write my commit messages.</p>
|
|
|
|
<p>I can write as much information as I need, I have coloured columns for the 50 character subject limit and the 72 characters for wrapping the body message and, if I write more than that, it will either wrap for me, or I can format the message for it to be compliant.</p>
|
|
|
|
<p>These are rules that aren't also enforced in some Git tools, so I prefer knowing my setup is configured correctly.</p>
|
|
|
|
<p>Though, whether you use <code>-m</code> or not, capture as much information in the message as you can, as future Developers on the project (including you) will thank you for it.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>A lot of tutorials show using <code>git commit -m</code> to create commits using an inline message.</p>
|
|
|
|
<p>I don't do that, though.</p>
|
|
|
|
<p>Using the <code>-m</code> option to specify an inline commit message encourages writing short one-line commit messages instead of using the subject and body effectively to document more about the change, such as why it was needed, any other approaches taken and the consequences of the change within the commit.</p>
|
|
|
|
<p>Alternatively, people could write a longer commit message in one line and not follow the 50 character limit for the subject line.</p>
|
|
|
|
<p>Whilst it's possible to write multi-line commits on the command-line, I use my editor (Neovim) to write my commit messages.</p>
|
|
|
|
<p>I can write as much information as I need, I have coloured columns for the 50 character subject limit and the 72 characters for wrapping the body message and, if I write more than that, it will either wrap for me, or I can format the message for it to be compliant.</p>
|
|
|
|
<p>These are rules that aren't also enforced in some Git tools, so I prefer knowing my setup is configured correctly.</p>
|
|
|
|
<p>Though, whether you use <code>-m</code> or not, capture as much information in the message as you can, as future Developers on the project (including you) will thank you for it.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|