From ba926e073e7f6d059b3d1b2c6407bfd6e30020f8 Mon Sep 17 00:00:00 2001 From: Oliver Davies Date: Mon, 20 May 2024 00:15:57 +0100 Subject: [PATCH] Add daily email for 2024-05-17 Why I don't commit with -m --- source/_daily_emails/2024-05-17.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 source/_daily_emails/2024-05-17.md diff --git a/source/_daily_emails/2024-05-17.md b/source/_daily_emails/2024-05-17.md new file mode 100644 index 00000000..cbcacd72 --- /dev/null +++ b/source/_daily_emails/2024-05-17.md @@ -0,0 +1,27 @@ +--- +title: Why I don't commit with -m +date: 2024-05-17 +permalink: archive/2024/05/17/why-i-dont-commit-with--m +tags: + - software-development + - git +cta: ~ +snippet: | + Why I don't use `git commit -m` when committing changes. +--- + +A lot of tutorials show using `git commit -m` to create commits using an inline message. + +I don't do that, though. + +Using the `-m` 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. + +Alternatively, people could write a longer commit message in one line and not follow the 50 character limit for the subject line. + +Whilst it's possible to write multi-line commits on the command-line, I use my editor (Neovim) to write my commit messages. + +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. + +These are rules that aren't also enforced in some Git tools, so I prefer knowing my setup is configured correctly. + +Though, whether you use `-m` 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.