Was digging through a project at work today where some guy in 2014 made 100+ commits in a single day and the only one that had a comment said “upgrading to v4.0”.
git commit -m “minor tweaks”
+3,276 -4,724
Bug fixes. Too many to count.
I had one of those and it was two in the night and I was tired and forgot what I did and committed
stuff, I dunno.But normally I’m a good boy and prefix with the ticked id and write down the change and attempted fix.
[issue number] short summary
description of main changes, bullet list if there are lots.
description of minor changes.
motivation of this change, if unclear.
Literally about 90% of the commits I’ve pushed on my DayZ server’s configs and mod files are just marked ‘a’. The actual mod updates I almost never have made porch notes for. Trying to be a little more informative for my new D&D based Conan Exiles server.
It still looks better than how I used to name things in flash.
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.
That’s pretty neat. Is there a forked version that adds ticket number as a mandatory first class citizen? Cause that’d be darn near perfect.
Enforced by pre-commit, conventional commits has cleaned up our commit logs and changelog so much.
I totally agree.
Right now I’m on a new project with a teammate who likes to rebase PR branches, and merge with merge commits to “record a clean history of development”. It’s not quite compatible with the atomic-change philosophy of conventional commits. I’m thinking about making a case to change style, but I’ve already failed to argue the problem of disruption when rebasing PR branches.
deleted by creator
I feel like this might be a good case for LLMs… Auto git commit suggestions based on the diff.
@CanadianNomad @lucas Awesome idea, yeah I can totally see that working well :)
deleted by creator
If it does, I haven’t seen it… I’d be happy to test drive it.
There are already some attempts but I don’t think it will work, harmful even. Best case scenario, the AI can understand the code as well as a senior engineer from another company. All they can know without the context is what was changed, which is useless. We need the reason why the commit was made, not what was changed. The info is not there in the first place for the AI to try to extract.
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.
On projects I setup I have prettier run as part of a commit hook. All files will be formatted at all times
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.
Developer intials seems a tad redundant since the commit is tied to author(s). But I guess it is only 2 extra char
I try to follow the BLUF pattern: Bottom line up front. The first line is as short a description of the change (“Re-fixed a bug where a URL without a verb could crash the bot.”) with some detail following (“I thought I caught that a couple of years back…”)
I try to save the detail for the code itself: Comments describe what I was thinking at the time for context, the code is the code. I don’t replicate the code comments in the commit message because having the same thing in two places means having to keep two things up to date, and that rarely goes well.
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
- “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.
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
ah nice. we include the backlog # in our branch name.
deleted by creator
I did this thing that fixed ticket #1618
For features:
I did this thing and X feature is now implemented. This closes out work for #1618
I try to follow https://www.conventionalcommits.org/en/v1.0.0/
For me, the need it: when production is on fire, as a responsible person, I want to be able to understand why the change of this commit has been made. Perhaps also what were the drivers of the implementation.
I also have this onliner to commit and push each 10min:
watch -n 60 'git add . ; git commit --allow-empty-message -m "" ; git push'But those commits would never be merge as they are to master or main. It’s just if I loose work on my laptop. Worst case a
git rebase HEAD~has to be done before the PR review.[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
