It seems like the author is not aware of IDE annotation feature that allows one to inspect the latest commit that modified any line of code. Better commit message helps there for sure. I use this all the time, saves time not having to lookup the PR and piece together why something changed by manual inspection.
Better commit messages would be more helpful with PR review process if it was easier to review commit by commit which is possible but rather cumbersome.
As someone who has both cursed and blessed the names popping up in git blame as I’m trying to understand why something is the way it is; I cannot even begin to sympathize with this.
The author has a seemingly naive notion of the lifecycle code; commit messages matter a lot less if you have deep thorough documentation in the general case.
But obviously not all code is being written in those types of environments. In fact I’d venture the vast majority of commits have no associated code review thread.
Sometimes my little project I’m working on myself , which has no code reviews, eventually gets grows and has others involved; but the early history remains.
Indeed. Author seems like someone who has never used git blame or something. Also, given that I originally used mercurial for the first few companies I worked at in my career, this idea of just blowing away history with squashes and rebases etc is anathema to me.
I have neither the motivation nor the energy to start an internet argument about it, but I’d like to reassure the casual reader that this post is promoting a minority viewpoint.
I disagree that the vast majority of commit messages are you describe. But even if that were the case, I don't think the majority of commit messages being bad would mean they don't matter.
If comments are often considered harmful because of their lacking quality, why would commit messages be considered helpful when they suffer from similar issues?
One reason is that commit messages do not become stale.
Anyway, software development as a whole decided on a pretty stable set of comments that are considered helpful. Commit messages are clearly in there, as well as API elements description.
In addition to the staleness argument (which is somewhat countered by its inverse: the good, helpful commit message might be hidden under a huge layer of naming convention changes and the like), there's also the off by default. A comment always helps itself to some mental bandwidth, whereas the commit is nicely tidied away unless you ask for it.
Descriptively, I do find the default level of rigor to commit messages to be low. Even in repos with really good messages, it is an act of discipline to get them that way and keep them that way. And if there is anything we should all be able to agree on, it's that strong discipline is not the norm in software development as a whole.
Note I'm not arguing for that as a prescriptive state. I think a good commit log is a good thing and can see that there are different ways of getting there.
> I disagree that the vast majority of commit messages are you describe.
Sorry but I feel like you have to be just in denial then.
> But even if that were the case, I don't think the majority of commit messages being bad would mean they don't matter.
OK but I think if it's the case it's fair to say hte majority of developers don't agree, whereas you stated it was an industry wide opinion that they are. I think commit messages are mostly stupid and the git UX is absolute trush. Theoretically, if the git UX weren't trash, they could matter, but it is so they don't.
I never claimed to be stating an industry-widr opinion. I was disagreeing based on my own personal experience. Based on upvotes and other comments, it seems I am not alone in this opinion.
> The reality is that developers convey intent through pull requests
They really don’t.
That doesn’t mean they convey it through commit messages either, mind.
But the latter is definitely the worse sin. Having the information in the commit message is much easier to access (especially with a good editor), and it’s way less likely to be lost.
PR discussions are often a trawling mess of historical baggage, if something has been discussed back and forth for 6 months I’m generally a lot more interested in a final summary of the whats and the whys, than having to go through the entire thing every time.
That’s why the NTSB produces reports, they don’t just publish thousands of hours of raw investigation footwork.
Well, that's how the commit messages in my feature branch look like. It's nothing like the commit message that will end up in the main branch, which usually fills half a terminal page.
At work, there are a lot of trivial commits, and I don't mind. What I do mind is if something breaks, I go looking at commits, and there are no ticket numbers or other tracking info mentioned in the commit or merge request.
I discourage that, unless it's very minor! Major code cleanup gets its own ticket. But if it's just fixing a minor spelling issue etc. then no, why would requiring the ticket number to be in the commit be an issue?
> Not sure there's evidence there. I bet if you look over the vast majority of commit messages you will find that they're "lol fuck" or "whoops".
Yeah the Linux Kernel tree is _littered_ with those, it's a real pain /s. To be more serious, any workflow that's a tiny bit serious about technical debt will plain reject a PR that's littered with those. I have no problem with rejecting a PR with obvious commits like those. In a professional setting it's vital to keep codebases manageable, especially if those are in the tens.
> The reality is that developers convey intent through pull requests and rarely go through a commit log.
Not really. Pull request are usually a 1:1 mapping with an user story / ticket id / bug id, etc. They might require multiple changes in multiple places with their own reasoning.
The author ignores the possibility of writing a terse but just descriptive enough message that gives an idea of what the changes were, which I would call a "good" commit message.
My team writes good commit messages… I had to revert a giant feature due to unforeseen consequences. Because of this I didn’t have to diff anything, I selected the target commits, made a revert commit, and was done.
Saved me hours of time and headaches. This is my anecdotal example from the last month for why this article is wrong.
Write good commit messages, people can and do read them. When it matters, it matters a lot.
> Proper style? Formatting. Imperative voice. Capitalization. Hard wraps.
Correct, those don't matter much. On the other hand, describing what the change is about matters a lot.
It is 10x easier to review a merge request when you can see discrete steps that make sense (ex: update method X, update route Y that calls X, update all code paths that use route Y, update client to handle new data) vs one big jumble of "stuff", "fix it", "update getCustomers" that touches 27 places at once.
Not a fan of those arbitrary limits. It's all about being able to quickly understand the changes and their reason to be. If splitting the updates in smaller increments help, then so be it, and I'll take ten tidy small commits over two large ones any day.
PR guidelines - Git best practices generally - are one of those situations where you must provide concrete guidelines but also never, ever make them a hard rule. If you don't have any you'll get endless "fix" "oops" +9876/-1234 changes, and if you make them a hard rule you'll never get anything useful done as people spend all day trying to please the aesthetic preference of a team lead who probably hasn't written a more than a single two line commit in years.
Huh? The number of commits is irrelevant - the number of changed lines/ files is what matters. 20 commits can result in a couple of lines in one file changing (I've seen it happen) and 1 commit can have 100s of files changed (usually when some commonly used symbol has been renamed).
By grouping the changes logically (by system, context, feature, up to you), as in the example I gave. Sometimes it's as simple as putting backend & frontend changes into separate commits for easier review.
Of course you still need an overarching description in the merge request - should be really easy to write, when you have all the steps taken right in front of you.
This assumes that people work in logical, sequential chunks. I don't. I do a little here, a little there, and then it all starts to form the larger picture.
Not necessarily, I don't think anyone works linearly, but you can still keep your commits organized. I might have 25 dirty files and a bunch of WIP commits; when I'm done I will reset everything, and take the time to stage them one by one (or `git add -p`) into commits that make sense, and will help a reviewer understand what's happening. It's worth the extra few minutes.
For a more concrete example, say you're adding a new screen to a mobile app, I'll probably split into chunks like these:
- add new `/foo` endpoints to API
- add `NewScreen` (can be reviewed as a feature, does the screen contain / do what it's suppose to)
- add `NewScreen` to navigation stack
- link to `NewScreen` from settings page
- add tracking for `NewScreen`
Each of these have very different purposes, and I find being able to focus on the different aspects (business logic, infrastructure stuff, analytics) helps a lot. They can also be reverted cleanly if needed without destroying all of the work.
You can still review the entire PR at once, with the option to drill down into individual commits if desired.
Assuming your original commits are atomic but not complete (that is each feature / chunk of work is spread over multiple commits as you changed things up or fixed things you’d forgotten) `rebase -i` might be significantly superior to resetting and redoing everything by hand.
That's why working on a branch, and once ready, taking the time to reorganize your commits into logical steps, is a basic act of kindness towards the people who will review your changes, and towards your own future self.
I would argue that if you can't communicate the purpose of the change in a simple commit message then you have probably combined too many things into the commit.
Breaking this rule is one of my bad habits and it's annoying for my colleagues to review and increases the risk of including some unintentional change ("I'll just edit this config file for some local testing...") as it gets lost in the noise.
>If the update is going to touch 27 places at once, how is the developer meant to communicate such a change thru commit messages?
I make the commit messages also for myself, how many time you find some code and wonder why is it like that, then you search git and find if lucky a nice message with a ticket id and if you are lucky again the ticket has clear details on what was the issue that was fixed and what behavior was requested.
Based upon username will assume author shared it here:
You've neglected to state what commit messages do matter, unless you think none do.
In my experience, commit messages only don't matter if the code is never used beyond the first creation.
Once you have to maintain the code, commit messages absolutely matter.
Does it need to include the granular details mentioned in the article? No. But commit messages help determine what commits should be reviewed during maintenance (including adding new functionality).
(I also experienced a touch of cosmic fear while reading the article, thinking about someone who might rebase or squash every commit, leaving only one commit for an entire repo.)
It wholely depends on what you are hoping to get out of the commit messages.
I don't want to see the local commit history of individual developers in the commit history of any shared branches (be it mainline branches or shared development branches).
What I do want to see is a history of pull request merges. I don't care how they are formatted (and this is often done automatically) but it matters that if I want to check out a historical changeset that I can. This is particularly useful when there are regression bugs that managed to slip through the QA and automated testing processes and it is unclear what caused them and when. It is nice to be able to go through the commit log and identify suspect work items, check out the commits during that time and see what they changed.
How you format the commit messages isn't that import as long as your pull-requests are squashed-merged (to suppress local dev workflow commits that aren't relevant to the team) and the commit messages facilitate doing that with something that links back to a work item.
> Commit messages are probably one of the worst places for documentation
They're a bad place for documenting the repository for users. They're about the sole place to document what's in the _commit_...
> and a common source of bikeshedding.
You can bikeshed anything if you like. But I'll grant the author's claim that bikeshedding the exact format convention of commit messages is excessive. If someone wrote "Added feature X" as opposed to "Add feature X" - yeah, that doesn't really matter.
On the other hand, if the first line of a commit message is extremely broad and vague, this makes it difficult for the developer browsing the commit history in a one-line-per-commit view.
> Adding in information about what files have changed doesn't make sense
It can makes sense if it's essential to the commit, e.g. "Moved `foo` from `file1.h` to `file2.h`". But TBH - this is bikeshedding.
> this information is more easily stored by looking at the diff
Ah, but the whole point is that you want to _avoid_ looking at the diffs of many commits.
> Information about why and how often have better homes.
Nope.
> There's the code review history, the bug tracker
These are not part of the VCS commit history, and may not even exist at all.
> the code comments
So, we want to put commit comments as actual comments now? No.
> and the actual documentation.
No. The actual documentation is:
1. Intended for users of the repository rather than developers/maintainers of the repository.
2. Documents all commits up some release (or up to some commit).
> Your commit message essays will probably be lost or munged anyway – squashed, merge committed, or rebased.
So will our code... but the point is that, after such squashes etc., there is still a commit history for which it is important and useful to have commit messages.
The worst commit message bureaucracy is the requirement to link to a story / feat|bug|etc classification and perfect message formatting or it gets rejected.
My firm went through 3 different ticket systems in 5 years, including a round trip to Jira. Teams/apps migrated to different Jira projects, repos got split apart/merged, tickets were archived, etc.
So the commit blocking requirement of having a link to the story ends up pointing to dead ends or stuff you may not have access to quite often.
This is the kind of stuff that causes senior devs to commit less often, or to have an always-open "misc" ticket to book everything to, with a copy-paste ready commit message in the proper format to pass checks.
As a team lead I insist on a link to a ticket for stuff that is related to a ticket. When moving to another ticket system, I insist either on keeping older projects on the old system, or alternatively on migrating old tickets to the new system and keeping the original references; the same way I insist on keeping history when moving from one source control system to another one.
Also... why would a company go through 3 different ticket systems in 5 years? That must cost a lot and definitely is not gonna help convincing people to use it...
> Your commit message essays will probably be lost or munged anyway – squashed, merge committed, or rebased.
Yes, because commit messages do matter and rebasing/squashing is how you clean up your initial draft commits. (Merging doesn't lose or munge the commits.)
I can see where the author's coming from. However, my approach for a PR might be a bit of a mix. Normally, I aim to make a PR be reviewable, commit by commit. However, in some cases, due to a semicolon missing (you get the point), or some instance where I'm being daft, or me bumbling in the dark trying to fix a piece of ancient, undocumented code, the history might end up being less than clean. The messages will always describe my train of thought in those scenarios, but the overall history wouldn't be cut and dry.
I tend not to worry about that and generally just squash the commits when I merge, so that, on main, there's a single commit for a particular feature. That's an overall piece of work I did. If someone wants to dig into a feature commit by commit, they can typically check the PR out and do it that way, but in practice, I've rarely seen that happen, and if it did, it was more for the overall feature rather than any one commit.
So, overall, it's not that commit messages don't matter, but rather that, while a pristine history is always nice to see, it's not always possible without unnecessary head scratching that generally just costs more dev time for very little benefit.
You know that you can edit the history in order to fold the small fixes and mistakes back into the commit they belong to right? It’s not an all or nothing situation.
> If someone wants to dig into a feature commit by commit, they can typically check the PR out and do it that way, but in practice, I've rarely seen that happen
Of course not, it’s a pain in the ass having to go back to the PR and trawl through a commits sequence you describe as essentially broken.
I know that, but what advantage do you get from trawling through a commit sequence, over the general feature with proper documentation? If you can't understand how the overall feature was implemented, that PR generally speaking is lacking enough context to be reviewed, so why did it get merged in?
Commit messages don’t matter. In fact they matter so little that I'm going to write a blog post about how much they don't matter. Commit messages are probably one of the worst places for documentation and a common source of bikeshedding. So let me kickstart some more bikeshedding since there's not enough already.
I work at a large software company that has, for decades, operated without any commit messages whatsoever. When you get the days latest code in your workspace, you know what files are changed, but not why (and often not who). Has our company imploded? No. But you absolutely feel this lack of information whenever you wonder "hmm, why is this line of code the way it is".
As we've transitioned to git, we don't have a universal culture of writing commit messages, and I wish we did.
Amen. My company has a fixation with it and yet no use. Zero.
The only instance where it paid off was to include the jira task code in the second line of the commit, but this also has been short sighted and rarely useful because most discussion about PRs happens on slack and teams, not on Jira.
This sounds like the advice of someone who hasn’t worked in codebases mature enough to go through multiple source control system and issue tracking system changes. The commit message is the one piece of documentation most likely to survive. A commit message that explains why the change was made can be very valuable when the code review comments and bug report are no longer available.
> There's the code review history, the bug tracker, the code comments, and the actual documentation. All of which are probably better places for real knowledge to be stored.
The funny thing is that I've been through many of these systems in the past years, and each time we mostly lost all the previous PRs and comments, but all my commit messages are still there preserved in the history.
These ideas are all a "better place" until it's suddenly all gone because it's not actually a part of your code history and can't easily be moved.
Bug tracker? It can change. Reviews discussion? The tool can change. You get the point.
As an added pain point, I don't want to juggle different tools to get the whole picture about changes. I don't want to copy/paste a Jira ticket reference in my browser from my terminal to get the reasoning about the change. I don't want to copy/paste a bugtracker ID to get the reasoning about the change.
Commit messages are here for a reason, and it is to document the change. I find them invaluable when digging through a codebase with plain git tools, tig, or the git integration of an IDE. Conversely, this is why I hate squashes of PRs of more than X commits. Just no.
For this, I often configure repos to only accept "fast-forward merges", as to keep a linear history. The added benefit is increased by good splitting of commits as conflicts will be resolved commit by commit rather than the whole PR with a possibly huge conflict to solve.
But commit messages can also be too fine-grained, at least if you are not into the squashing game. And a level of conciseness that is valuable in commits might be a little too short for truly meaningful context years later. My preferred pattern is some "why" in the message, as a soft "should", and a external reference to some potentially longer and perhaps not so fine-grained ticket/story/bugtracker-id as a much stronger "should". That's where longer form prose has its place, or some media, and most importantly after the fact amendments without the hassle of history rewriting. And once that pattern is 80% established, even the emotional outlet of an occasional "whoopsie" message can be totally worth the cost, if it's actually "whoopsie (WHYJIRA-12345)"
Anything occasionally gets lost. (some languages have surprisingly useful decompiles..) It's probably best if all approaches are taken in parallel. And taken reasonably well (as opposed to gold plating), enough to be workable alone in a pinch but decidedly not fully redundant. Comments, commits and out-of-band tickets all have their place and neither is a good substitute for the others. Allow them to complement each other, and strive for just enough overlap to make losses somewhat tolerable.
93 comments
[ 6.1 ms ] story [ 146 ms ] threadBetter commit messages would be more helpful with PR review process if it was easier to review commit by commit which is possible but rather cumbersome.
The author has a seemingly naive notion of the lifecycle code; commit messages matter a lot less if you have deep thorough documentation in the general case.
But obviously not all code is being written in those types of environments. In fact I’d venture the vast majority of commits have no associated code review thread.
Sometimes my little project I’m working on myself , which has no code reviews, eventually gets grows and has others involved; but the early history remains.
The reality is that developers convey intent through pull requests and rarely go through a commit log.
Most people use commits as "ctrl s", which means commit messages are just some dumb shit in the way of me backing up my files.
If comments are often considered harmful because of their lacking quality, why would commit messages be considered helpful when they suffer from similar issues?
Anyway, software development as a whole decided on a pretty stable set of comments that are considered helpful. Commit messages are clearly in there, as well as API elements description.
I have no idea what you're talking about.
Note I'm not arguing for that as a prescriptive state. I think a good commit log is a good thing and can see that there are different ways of getting there.
Sorry but I feel like you have to be just in denial then.
> But even if that were the case, I don't think the majority of commit messages being bad would mean they don't matter.
OK but I think if it's the case it's fair to say hte majority of developers don't agree, whereas you stated it was an industry wide opinion that they are. I think commit messages are mostly stupid and the git UX is absolute trush. Theoretically, if the git UX weren't trash, they could matter, but it is so they don't.
I never claimed to be stating an industry-widr opinion. I was disagreeing based on my own personal experience. Based on upvotes and other comments, it seems I am not alone in this opinion.
They really don’t.
That doesn’t mean they convey it through commit messages either, mind.
But the latter is definitely the worse sin. Having the information in the commit message is much easier to access (especially with a good editor), and it’s way less likely to be lost.
PR discussions are often a trawling mess of historical baggage, if something has been discussed back and forth for 6 months I’m generally a lot more interested in a final summary of the whats and the whys, than having to go through the entire thing every time.
That’s why the NTSB produces reports, they don’t just publish thousands of hours of raw investigation footwork.
Yeah the Linux Kernel tree is _littered_ with those, it's a real pain /s. To be more serious, any workflow that's a tiny bit serious about technical debt will plain reject a PR that's littered with those. I have no problem with rejecting a PR with obvious commits like those. In a professional setting it's vital to keep codebases manageable, especially if those are in the tens.
> The reality is that developers convey intent through pull requests and rarely go through a commit log.
Not really. Pull request are usually a 1:1 mapping with an user story / ticket id / bug id, etc. They might require multiple changes in multiple places with their own reasoning.
Saved me hours of time and headaches. This is my anecdotal example from the last month for why this article is wrong.
Write good commit messages, people can and do read them. When it matters, it matters a lot.
Correct, those don't matter much. On the other hand, describing what the change is about matters a lot.
It is 10x easier to review a merge request when you can see discrete steps that make sense (ex: update method X, update route Y that calls X, update all code paths that use route Y, update client to handle new data) vs one big jumble of "stuff", "fix it", "update getCustomers" that touches 27 places at once.
Of course you still need an overarching description in the merge request - should be really easy to write, when you have all the steps taken right in front of you.
For a more concrete example, say you're adding a new screen to a mobile app, I'll probably split into chunks like these:
Each of these have very different purposes, and I find being able to focus on the different aspects (business logic, infrastructure stuff, analytics) helps a lot. They can also be reverted cleanly if needed without destroying all of the work.You can still review the entire PR at once, with the option to drill down into individual commits if desired.
Breaking this rule is one of my bad habits and it's annoying for my colleagues to review and increases the risk of including some unintentional change ("I'll just edit this config file for some local testing...") as it gets lost in the noise.
I make the commit messages also for myself, how many time you find some code and wonder why is it like that, then you search git and find if lucky a nice message with a ticket id and if you are lucky again the ticket has clear details on what was the issue that was fixed and what behavior was requested.
You've neglected to state what commit messages do matter, unless you think none do.
In my experience, commit messages only don't matter if the code is never used beyond the first creation.
Once you have to maintain the code, commit messages absolutely matter.
Does it need to include the granular details mentioned in the article? No. But commit messages help determine what commits should be reviewed during maintenance (including adding new functionality).
(I also experienced a touch of cosmic fear while reading the article, thinking about someone who might rebase or squash every commit, leaving only one commit for an entire repo.)
I don't want to see the local commit history of individual developers in the commit history of any shared branches (be it mainline branches or shared development branches).
What I do want to see is a history of pull request merges. I don't care how they are formatted (and this is often done automatically) but it matters that if I want to check out a historical changeset that I can. This is particularly useful when there are regression bugs that managed to slip through the QA and automated testing processes and it is unclear what caused them and when. It is nice to be able to go through the commit log and identify suspect work items, check out the commits during that time and see what they changed.
How you format the commit messages isn't that import as long as your pull-requests are squashed-merged (to suppress local dev workflow commits that aren't relevant to the team) and the commit messages facilitate doing that with something that links back to a work item.
They're a bad place for documenting the repository for users. They're about the sole place to document what's in the _commit_...
> and a common source of bikeshedding.
You can bikeshed anything if you like. But I'll grant the author's claim that bikeshedding the exact format convention of commit messages is excessive. If someone wrote "Added feature X" as opposed to "Add feature X" - yeah, that doesn't really matter.
On the other hand, if the first line of a commit message is extremely broad and vague, this makes it difficult for the developer browsing the commit history in a one-line-per-commit view.
> Adding in information about what files have changed doesn't make sense
It can makes sense if it's essential to the commit, e.g. "Moved `foo` from `file1.h` to `file2.h`". But TBH - this is bikeshedding.
> this information is more easily stored by looking at the diff
Ah, but the whole point is that you want to _avoid_ looking at the diffs of many commits.
> Information about why and how often have better homes.
Nope.
> There's the code review history, the bug tracker
These are not part of the VCS commit history, and may not even exist at all.
> the code comments
So, we want to put commit comments as actual comments now? No.
> and the actual documentation.
No. The actual documentation is:
1. Intended for users of the repository rather than developers/maintainers of the repository.
2. Documents all commits up some release (or up to some commit).
> Your commit message essays will probably be lost or munged anyway – squashed, merge committed, or rebased.
So will our code... but the point is that, after such squashes etc., there is still a commit history for which it is important and useful to have commit messages.
My firm went through 3 different ticket systems in 5 years, including a round trip to Jira. Teams/apps migrated to different Jira projects, repos got split apart/merged, tickets were archived, etc.
So the commit blocking requirement of having a link to the story ends up pointing to dead ends or stuff you may not have access to quite often.
This is the kind of stuff that causes senior devs to commit less often, or to have an always-open "misc" ticket to book everything to, with a copy-paste ready commit message in the proper format to pass checks.
Also... why would a company go through 3 different ticket systems in 5 years? That must cost a lot and definitely is not gonna help convincing people to use it...
Yes, because commit messages do matter and rebasing/squashing is how you clean up your initial draft commits. (Merging doesn't lose or munge the commits.)
I tend not to worry about that and generally just squash the commits when I merge, so that, on main, there's a single commit for a particular feature. That's an overall piece of work I did. If someone wants to dig into a feature commit by commit, they can typically check the PR out and do it that way, but in practice, I've rarely seen that happen, and if it did, it was more for the overall feature rather than any one commit.
So, overall, it's not that commit messages don't matter, but rather that, while a pristine history is always nice to see, it's not always possible without unnecessary head scratching that generally just costs more dev time for very little benefit.
Github, sadly, very much is not designed for that.
> If someone wants to dig into a feature commit by commit, they can typically check the PR out and do it that way, but in practice, I've rarely seen that happen
Of course not, it’s a pain in the ass having to go back to the PR and trawl through a commits sequence you describe as essentially broken.
As we've transitioned to git, we don't have a universal culture of writing commit messages, and I wish we did.
The only instance where it paid off was to include the jira task code in the second line of the commit, but this also has been short sighted and rarely useful because most discussion about PRs happens on slack and teams, not on Jira.
The funny thing is that I've been through many of these systems in the past years, and each time we mostly lost all the previous PRs and comments, but all my commit messages are still there preserved in the history.
These ideas are all a "better place" until it's suddenly all gone because it's not actually a part of your code history and can't easily be moved.
Bug tracker? It can change. Reviews discussion? The tool can change. You get the point.
As an added pain point, I don't want to juggle different tools to get the whole picture about changes. I don't want to copy/paste a Jira ticket reference in my browser from my terminal to get the reasoning about the change. I don't want to copy/paste a bugtracker ID to get the reasoning about the change.
Commit messages are here for a reason, and it is to document the change. I find them invaluable when digging through a codebase with plain git tools, tig, or the git integration of an IDE. Conversely, this is why I hate squashes of PRs of more than X commits. Just no.
I like them because of the linear history, but the commit message should keep the explanation for _all_ the changes.
Anything occasionally gets lost. (some languages have surprisingly useful decompiles..) It's probably best if all approaches are taken in parallel. And taken reasonably well (as opposed to gold plating), enough to be workable alone in a pinch but decidedly not fully redundant. Comments, commits and out-of-band tickets all have their place and neither is a good substitute for the others. Allow them to complement each other, and strive for just enough overlap to make losses somewhat tolerable.