I have found it to be a sign of inexperience when devs protest "good" (whatever that means to you) commit messages.
They seem to have never worked with legacy code that has a good commit history you can rely on.
Arguing commits break flow would likely come from the same mouth that comments are useless and the code is self documenting. The "doesn't write code thinking of others" type.
I've actually found the opposite to be true. That usually the people harping for rich commit messages are the ones not thinking of others. That they are trying to get their coworkers to bend or produce extra work just to make their personal workflow more ergonomic. The information they seek is already redundantly documented, often 3 times over in the form of PR messages, jira tickets, requirements documents, slack history, etc.
In a perfect world yes that is true, but I've worked at multiple places where Jira got reshuffled by someone and either entire projects got deleted or ticket ids were reset.
Slack history and requirement documents are rarely linked in commit messages and looking through thousands of documents and channels to search the context of a commit is nauseating.
There's never a need to write an essay in a commit message, but 2-3 paragraphs won't kill anybody either.
But are they at all discoverable from the code base? Those PR messages, jira tickets, and slack history ought to be linked to in the commit message, and that requirements document checked in.
(None of those links help when you switch to different providers; but that might not be too bad, depending on timescales of those changes)
anything that is not in the commit message or in the commit itself is practically useless. documentation covers how to use a thing. it usually doesn't cover why a change was made. that why also normally does not end up in code comments, and even less so would be aparent from the change it self. the commit message remains the only place where the why can be documented meaningfully and along with the change where it is needed.
at least in my current project working with legacy code that i am not familiar with, the why is the most important detail about a commit.
Most teams I've been on just link to the PR from Jira and Slack. The PR links to the commit message, and the commit message explains the change.
Other stuff like "this is ready, can you review it?", or "we can ship feature X now" lives in the other tools.
Note that (in the rare case where you want to), you can then search for links to old PRs in the other tools. Also, putting the jira ticket number in the commit message usually makes sense.
I find writing commit messages helps my development flow:
Why did I spend an hour refactoring 1000 lines of rust code again?
It worked the first time I got it to compile again, so it's probably fine, but it was a subtle non-functional change. I'd better commit + write a good message so:
- I don't forget why I just did that
- In case I need to back out the next step
- So that my coworkers know what I'm up to, and don't ask me on slack.
when i am writing commit messages i am actually very focused. i study the changes and try to condense them into a helpful description. incidently i am working with legacy code now which has me studying the commit history forwards and backwards, and good commit messages that allow me to discover changes that i am interested in are really making a difference.
PRs are merged squash everywhere I worked, so whats the point? Commit messages are hardly ever useful for me working on a task for a few days or even weeks.
Git keeps the commit messages when using `git merge --squash`.
By default it will produce a commit message starting with `Squashed commit of the following:`
The contents of this message are staged in `.git/SQUASH_MSG`.
When using GitHub the squash merge commit behavior is configurable and the teams I've been on have kept it configured to keep the commit messages of the commits being squashed. I assume GitLab has similar functionality.
They seem to have never worked with legacy code that has a good commit history you can rely on.
Arguing commits break flow would likely come from the same mouth that comments are useless and the code is self documenting. The "doesn't write code thinking of others" type.