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
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.
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.
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
Followed by
fixed formatting
final formatting fix
you gotta be kidding me, fuck you, detekt!
I feel like this might be a good case for LLMs… Auto git commit suggestions based on the diff.
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.
@CanadianNomad @lucas Awesome idea, yeah I can totally see that working well :)
I simply commit to master with the message “git commit”.
