From 4be6a815807c99886af0fd5e3033c1d6c33d421a Mon Sep 17 00:00:00 2001 From: Oliver Davies Date: Tue, 28 Nov 2023 07:54:19 +0000 Subject: [PATCH] Add daily email for 2023-11-24 Are conventional commits worth it? --- src/content/daily-email/2023-11-24.md | 30 +++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 src/content/daily-email/2023-11-24.md diff --git a/src/content/daily-email/2023-11-24.md b/src/content/daily-email/2023-11-24.md new file mode 100644 index 00000000..b813927a --- /dev/null +++ b/src/content/daily-email/2023-11-24.md @@ -0,0 +1,30 @@ +--- +title: > + Are conventional commits worth it? +pubDate: 2023-11-24 +permalink: > + archive/2023/11/24/are-conventional-commits-worth-it +tags: + - software-development + - git +--- + +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 `feat`, `fix`, `chore`, `docs`, etc - and provide an optional scope before completing the subject line (the first line in the message). + +Then, it is encouraged to add a longer body to the message and provide any links and task IDs that the change relates to. + +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. + +I don't create automatic CHANGELOG files from the commit types. + +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). + +While I see value in writing descriptive commit messages, I'm unsure if I do to format the subject line in this way. + +## Here's the thing + +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. + +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? + +Which provides the most value when looking back at the Git log in the future?