I guess that depends on how detailed the commit messages are and how many changes they have, which will be affected both by the specifics of the project and the people in it.

Consider the following:

  [8 files changed] ISSUE-541 added DB migrations and repositories for the new functionality of managing Foos
  [2 files changed] ISSUE-541 refactor the DB migrations to do Bar before creating one of the views because of it breaking otherwise due to Baz
  [11 files changed] ISSUE-541 refactor old services to use the new Foo functionality, because it should be more consistent than using native queries with complex SQL
  [3 files changed] ISSUE-541 fix problems with fetching data in some of the old services, because edge cases were not covered, add unit tests to cover this functionality
  [7 files changed] ISSUE-541 add services for managing Foos, though they will only be used in ISSUE-544, add comments about this
  [20 files changed] optimize the imports in the Foos package and remove unused code (should automate this later)

And then the following:

  [3 files changed] DB migrations
  [1 file changed] refactor
  [4 files changed] refactor
  [1 file changed] fix code, add tests
  [2 files changed] services
  [6 files changed] formatting

In one of the cases, the changes are larger and therefore more meaningful descriptions of what each commit does are probably a good thing - if the refactoring of code would break anything that wouldn't be immediately apparent but would later be detected, being able to click in the commit in the IDE history and see what exactly was changed as a part of it could be pretty useful!

Whereas in the other case, there are fewer files changed, so the pattern that i've seen emerge is that most people won't care much about detailed commit messages, because of which it is no longer that useful.

Of course, i've also seen people (the majority of my coworkers, though it depends on the company) not really care about commit messages or even making smaller atomic commits at all, thus a feature branch could look like the following:

  [28 files changed] ISSUE-541
  [11 files changed] refactoring

Then again, the majority of people in my current company also always leave merge request descriptions completely empty and expect you to figure out what the code does by its contents alone in the diff, without providing any context or further considerations. Personally, i'm against this and while i don't want to sour our relationships by nagging about it, personally i always write out a bit of information about what each feature branch accomplishes, as well as even include a few images or GIFs.

That has made my own life much easier when something seemingly breaks 9 months down the line and no one has any idea why, whereas i can just look at the merge request for the offending code and see all of the charts and explanations i need.

Personally, i think that the closer your documentation (of any sort) is to your code, the better the end results.