oliverdavies.uk/content/node.aba40c6c-363c-489a-b1d3-b0ac5a5890bf.yml

100 lines
4 KiB
YAML

uuid:
- value: aba40c6c-363c-489a-b1d3-b0ac5a5890bf
langcode:
- value: en
type:
- target_id: daily_email
target_type: node_type
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
revision_timestamp:
- value: '2025-05-11T08:59:58+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: 'Writing good commit messages'
created:
- value: '2025-04-04T00:00:00+00:00'
changed:
- value: '2025-05-11T08:59:58+00:00'
promote:
- value: false
sticky:
- value: false
default_langcode:
- value: true
revision_translation_affected:
- value: true
path:
- alias: /daily/2025/04/04/good
langcode: en
body:
- value: |
<p>There are many good resources and interesting articles online about how to write good messages when committing changes to a Git repository.</p>
<p>The post I often refer to is <a href="https://cbea.ms/git-commit">How to Write a Git Commit Message</a> by Chris Beams.</p>
<p>In his post, he explains why good commit messages matter and gives these seven rules:</p>
<blockquote>
<ul>
<li>Separate the subject from body with a blank line.</li>
<li>Limit the subject line to 50 characters.</li>
<li>Capitalize the subject line.</li>
<li>Do not end the subject line with a period.</li>
<li>Use the imperative mood in the subject line.</li>
<li>Wrap the body at 72 characters.</li>
<li>Use the body to explain what and why vs. how.</li>
</ul>
</blockquote>
<p>I'd recommend reading the article to get the full context.</p>
<p>Rules two and six suggest lengths for the subject line and body which is another reason <a href="/daily/2025/04/02/commit">why I rarely use <code>-m</code></a> when committing changes.</p>
<p>Whilst you can create multi-line commit messages on the command line, by opening it in my preferred editor (Neovim for me), I can see where the lines should end and be warned if I exceed them.</p>
<p>I can even include Chris' rules in my commit message template so I see them whenever I'm about to commit something.</p>
<p>This additional feedback helps me create my commit messages how I intend.</p>
format: full_html
processed: |
<p>There are many good resources and interesting articles online about how to write good messages when committing changes to a Git repository.</p>
<p>The post I often refer to is <a href="https://cbea.ms/git-commit">How to Write a Git Commit Message</a> by Chris Beams.</p>
<p>In his post, he explains why good commit messages matter and gives these seven rules:</p>
<blockquote>
<ul>
<li>Separate the subject from body with a blank line.</li>
<li>Limit the subject line to 50 characters.</li>
<li>Capitalize the subject line.</li>
<li>Do not end the subject line with a period.</li>
<li>Use the imperative mood in the subject line.</li>
<li>Wrap the body at 72 characters.</li>
<li>Use the body to explain what and why vs. how.</li>
</ul>
</blockquote>
<p>I'd recommend reading the article to get the full context.</p>
<p>Rules two and six suggest lengths for the subject line and body which is another reason <a href="/daily/2025/04/02/commit">why I rarely use <code>-m</code></a> when committing changes.</p>
<p>Whilst you can create multi-line commit messages on the command line, by opening it in my preferred editor (Neovim for me), I can see where the lines should end and be warned if I exceed them.</p>
<p>I can even include Chris' rules in my commit message template so I see them whenever I'm about to commit something.</p>
<p>This additional feedback helps me create my commit messages how I intend.</p>
summary: null
field_daily_email_cta: { }