On my projects where the repository is shared between me and other programmers, I always write commit messages even if I'm the primary developer.

But on those projects where I'm the solo developer working on a project, and the repository is hosted on my personal laptop, and is not even hosted by the client, hence no one except myself would see the commits, should I still write commit messages?

So far I have been writing them, but I've found that I've never gone back and viewed my commit messages. I take time off development to write down the messages, but then they're never seen again even by me.

Are there any good reasons for writing commit messages as a solo developer, or should you just skip them in favor of staying focused on development?

"I've never gone back and viewed my commit messages" well the first time you'll have to go back, will probably provide you with that good reason. Actually, walking in your shoes, I'd probably do silent commits until that first go-back happens
–
gnatApr 30 '12 at 19:58

5

"I always write commit messages even if I'm the primary developer." You think that's unusual? Of course the primary developer should write messages, even moreso than the other developers (who already should 100% of the time).
–
AlbeyAmakiirApr 30 '12 at 22:16

6

Commit messages are pure gold when you start maintaining older versions of your software, and not just the newest.
–
user1249May 1 '12 at 8:49

10 Answers
10

Well here is one reason: If you suddenly realize something has been broken for the last few hundred commits (possible if you commit at every minor edit, less feasible if you, like me, commit only "stable" snapshots), you can more easily find where you've inserted the bug if you've written clear commit messages, rather than "bugfixes." (A colleague's favorite string, I believe). Sure, you can go with svn log or whatever SCM you are using, but it should be easier the other way around.

Also commit messages force you to think what exactly you have done as a change and, I believe, summing up in your mind how it would be best to continue improving the project.

+1 for the last paragraph. I find that writing a proper commit message takes pretty much zero time as I always know why I made the change.
–
Stephen DarlingtonMay 1 '12 at 8:41

3

For my solo stuff, I have my commit message before I work on something. I do a small thing (aim for 30-45 minutes... got a wife and kids here!), and commit it. Maybe you could call it commit driven development?
–
corsiKaMay 1 '12 at 21:17

I try to always. How many times do you look back and think, "Man what was I doing when I made this change." I do all the time. 30 seconds of writing a message can save you 20 minutes worth of work trying to remember.

Do you honestly believe that the overhead of typing around 40 to 80 characters in plain english is significant overhead for a commit, or are you looking for an excuse to be lazy?

Pehaps you problem is expressing in plain english why you made the change, in which case, you may need to the review the purpose of the change, even to the point of asking yourself do you really need to do it.

My advise is don't think that because you are flying solo you can break the rules. Remain professional at all times, and add meaningful commit messages. As noted by other reponders, one day you will be thankful of it.

Interesting to revisit this answer. I've taken a somewhat extreme position recently: no commit messages at all. But that's on a pretty flat HTML/JS project where I can't imagine ever attempting to track down a regression. Any effort spent writing commit messages would almost certainly be better spent somewhere else. (Not all projects are in this category!)
–
Steve BennettMar 4 '14 at 5:30

(The commit messages in the repo are just a copy of what goes in the ChangeLog.)

Yes, more than once I've gone back to an old commit message associated with a change which broke something (uncovered with the help of git bisect). The message helped me make sense of what I was doing.

In the ChangeLog you can tell when a function, type, macro or global variable was first introduced and when it was subsequently touched by changes.

But the main reason for writing detailed commit messages like these when working by yourself is this: you find bugs when doing this.

To write a detailed commit message has similar benefits to a code review of your commit by someone else. The value in a commit review is not so much that someone is checking your code, but that you have to explain your changes to another developer.

When you try to explain things, you sometimes find that they don't make sense.

Another reason: you can catch yourself making a useless change. By writing a detailed commit comment, you capture a high level view of what you are doing, and then sometimes you are confronted by the fact that it's not a good change.

I've sometimes made changes, when in the middle of writing the ChangeLog entry I realized that this was going to be a git reset rather than git commit -a.

While you have not come across the need to view your commit messages yet, you may be very grateful for them in the future. You should keep writing them even for yourself. There are many reasons they could be useful later (You forgot why you were adding a feature, locate missing files, etc.)

I always commit with a meaningful message about changes, and I do so frequently with incremental changes.

Is this always the most useful thing? No, there is no problem in doing so. If you need to revert to a previous stage in progress your messages will let you know where you are and what you've done. It also can be used to keep track of progress on a project. As for it being a viewed as some waste of time, is the 30 seconds it takes to jot down a sentence really that consequential?

I don't see any difference regarding commit messages whether you're working in a team or not. You remember what you did here or there only for a limited time, and after that it is the same as if someone else wrote it. So you should write messages as good as you would for the other people.