I simply commit to master with the message “git commit”.

git commit -m “minor tweaks”

+3,276 -4,724

The change written as a command

Until I get frustrated by something and just start committing “yeet”

When I eventually (usually) rebase, declarative statements of what the commit would accomplish if applied.

When I am testing CICD or generally need to push more frequently for whatever reason, it’s humor and angst all the way.

Ffffffuuuuuuuuu

Pls, why

Okay yeah that was important I guess.

(⁠╯⁠°⁠□⁠°⁠）⁠╯⁠︵⁠ ⁠┻⁠━⁠┻

Conventional commits all the way! Even if I don’t use the keywords (feat, fix, etc.) I always write the comment in imperative tense; the message should tell you what happens if you merge it.

You get two options.

Normally it’s a squashed commit of everything in a feature, with a commit message like:

[JIRA-1234] - Descriptive but Concise Name of Feature

But every now and then it’s multiple commits like:

quick fix
Ugh, fix typo
fuck fuck why doesn’t it work
Oh, I’m stupid

My commits tend to be pretty verbose. Here’s an example log from one of my projects.

I follow the standard imperative style for the commit title, and then I use the body to summarize any important internal changes, reflect on the overall project status (for example, what milestones this commit crosses or what other work it might enable or require), and state what I’m going to work on next. I’m sure some people find it too wordy, but I like having the commit history show lots of details about the overall status.

Edit: I always have a descriptive summary, i.e., never one word commits or similar.

I like my company’s style:

For issues:

<jira ticket> - [program][deliverable] did this to fix that

Problem: symptoms of the problem that future devs can use to figure out its the same problem

Root cause: why this is broken

Solution: how I fixed it, including the scope

Testing: what testing it has it gone through

Developer Initials - Jira ticket number which includes the project abbreviation and the ticket number - brief description:

DA - HHGTTG-42 - fix question answer format

If you need details you look in the ticket.

• “progress on [1], fixed linting [2]”
• “[1] completed, setup for [2]”
• “[3] and [4] completed”
• “fixed formatting”
• “refactoring [1] and [2]”
• “fix variable typos”
• “update logic in [2]”
• “revert package.json and regenerate package-lock”

All my commits have comments. I generally commit after completing a ‘block’ objective, a describe what that was but in very simple terms mostly in regards to the file/section with the most significant logic changes. I don’t always specify the file if I did tiny typos/linting/annotation across a bunch of them, because the logic is unaffected I know that the differences will be visible in the commit history.

My weakness is that I don’t do it often enough. If I’m working on [2] for several hours, I’ll only commit when I consider it minimally-viable (completed 2), or when moving between machines ([further] progress on 2). And I have a bad habit of not pushing every time I commit, just at the end of the day or when moving between machines (though a messy rebase hopefully made that lesson stick), or if somebody else on the team wants to review an issue I’m having.

[issue number] short summary

description of main changes, bullet list if there are lots.

description of minor changes.

motivation of this change, if unclear.

[JIRA-123] Quick summary of objective

Justification (if applicable) Bulleted, high-level overview of important bits Any relevant test results done that won’t also be done in CI

I’ve had commits called fuck

They fluxuate wildly between short and informative messages like “fixed regex validation on property A” and “I fucking hate prettier” when the build pipeline fails because I had a line that was 2 characters too long.

I always try to capture the reasoning behind why I am making the change. I wrote about this more here https://lencioni.medium.com/the-secrets-to-great-commit-messages-106fc0a92a25