If you are using AI tools to write code and still learning what good code habits look like, this decision matters sooner than people admit. You open a messy file and think the responsible move is to add more comments. That feels safe. It can also send your time to the wrong place and hide the real problem.
More comments or better commit messages? If the goal is preserving judgment, better commit messages win. When comments get longer, design is often getting weaker. Long code comments often pay off bad design debt. Long commit messages preserve decisions.
That is the part beginners miss. A comment beside the code can tell you what a line does right now. A commit message can tell you why the change happened, what constraint forced the move, and what tradeoff was accepted. A change is worth reading not because it lists more features, but because it changes your next decision.
The two sources behind this point land in the same place. Git's patch guide says the log message matters as much as the code, and future maintainers need the why, not just the how [S001]. Google's C++ style guide says comments should not repeat obvious code and should give higher-level context instead [S002].
This is not a case against comments. Keep comments when you need to explain a contract, a sharp edge, or behavior that is not obvious from the code itself. The bad version is the paragraph that only translates weak naming or muddy structure into English.
So if you are choosing where to spend effort, make obvious code clearer and make non-obvious decisions easier to find in the history. If the line is obvious, fix the code. If the decision is non-obvious, explain it in the commit history. Share this with the person who keeps asking for more comments when what they really need is more why.