Why is it necessary to enter commit messages?

Question

I have been using git for a while now, and I had a question. Why is it necessary to add commit messages when using git commit? I mean, I admit that it is quite useful for me in some cases when I actually want to explain what a specific change does to the project.

But why is it still made necessary to write a commit message? I mean what if I am committing a minor change like fixing a spelling mistake in my UI? Is it a good thing that this is made necessary? or would it be better/worst if this was optional?

Answer 1

Git 2.36 (Q2 2022) updates the contributor-facing documents on proposed log messages.

It illustrates why commit messages are mandatory/important.

See commit cdba029, commit 607817a, commit fa1101a (27 Jan 2022) by Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit 8376093, 11 Feb 2022)}

SubmittingPatches: explain why we care about log messages

Extend the "describe your changes well" section to cover whom we are trying to help by doing so in the first place.

SubmittingPatches now includes in its man page:

The log message that explains your changes is just as important as the changes themselves.

Your code may be clearly written with in-code comment to sufficiently explain how it works with the surrounding code, but those who need to fix or enhance your code in the future will need to know why your code does what it does, for a few reasons:

• Your code may be doing something differently from what you wanted it to do.
  Writing down what you actually wanted to achieve will help them fix your code and make it do what it should have been doing (also, you often discover your own bugs yourself, while writing the log message to summarize the thought behind it).

• Your code may be doing things that were only necessary for your immediate needs (e.g. "do X to directories" without implementing or even designing what is to be done on files).
  Writing down why you excluded what the code does not do will help guide future developers. Writing down "we do X to directories, because directories have characteristic Y" would help them infer "oh, files also have the same characteristic Y, so perhaps doing X to them would also make sense?".

Saying "we don't do the same X to files, because ..." will help them decide if the reasoning is sound (in which case they do not waste time extending your code to cover files), or reason differently (in which case, they can explain why they extend your code to cover files, too).

The goal of your log message is to convey the why behind your change to help future developers.

Answer 2

Git by default requires commit messages because in software development, it is practically necessary to communicate with other people, and the commit message is the best way to communicate a variety of details about the commit, including what it does, why the change is necessary, the benefits and downsides of the change, and why this change is better than alternatives. Communication is an essential skill in the workplace and in open source projects and that is also true for writing commits.

Sometimes, the other person to whom you are communicating is future you. I have in the past, I have used my commit messages to record details of the change which I had to recall and explain two weeks later to a colleague. I would not have remembered those details had I not written them down somewhere.

Even if the change is trivial, you will still want to know what it does. When you're looking through git log, you'll want to know if this is a CSS change, which might be the cause of your UI bug, or a typo fix, which probably is not. In any event, since many developers make lots of minor changes, not specifying a commit message for minor changes means that a significant number of changes would end up being without commit messages, leading to a confusing history.

In many cases, you can avoid these minor typo fixes and similar changes by squashing a fixup commit into an earlier commit in the series with git commit --fixup and then using git rebase -i --autosquash BASE to squash them. Then you don't have to enter a commit message and nobody will know you made a typo in the first place.

If you really want to skip it, you can, with the --allow-empty-message argument to git commit. However, as mentioned above, if you are working with others, they will probably not appreciate that style of commit.

Answer 3

If it were optional, users would have the option of omitting it even when they really should be explaining what got changed.

If it's not optional, users are at worst mildly inconvenienced by having to make up a trivial commit message like "fixed a typo".

Ideally, you should be able to look at the output of git log --oneline and still get an idea of what changes have been made. Consider this log:

a2b2c3 Fix another critical error in bar
abcdef
123456 Introduce critical method bar

Do you want to assume that abcdef is a minor typo that someone decided wasn't worth a comment, or should you assume that it's a major bug fix implied by the use of "another" in the next commit?

---

Strictly speaking, it's not necessary; it's just the default to enforce adding a commit message. You can use git commit --allow-empty-message to proceed without one.