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?

  • 14
    "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
    – gnat
    Commented Apr 30, 2012 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). Commented Apr 30, 2012 at 22:16
  • 7
    Commit messages are pure gold when you start maintaining older versions of your software, and not just the newest.
    – user1249
    Commented May 1, 2012 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.

  • 13
    +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. Commented May 1, 2012 at 8:41
  • 5
    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?
    – corsiKa
    Commented May 1, 2012 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.

  • 12
    It also helps when creating a monthly report. The list of commit messages is a great start for the report Commented Apr 30, 2012 at 20:03
  • 2
    Yeah, and it really only takes one time where you need it to pay back the for the time it takes doing the comment.
    – tzerb
    Commented Apr 30, 2012 at 21:59

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.

  • You won't always be a solo developer.

  • You will eventually break your codebase and attempt to restore it. Good commit messages will save you hours.

  • You can't remember what you were working on three weeks ago, right?

  • Commit messages should be very clear. If they are not, then you have either didn't finish working on a task, or a single task has spread over two or more tasks.


Definitely, or else you make features like branching and merging a lot harder to use. And you will want to use them, even if solo developer.


One possible reason to: it forces you to think more abstractly about the change you've just made, and to structure changes.

If it feels pointless, perhaps just comment the major changes, or the ones that change existing functionality, in case you are ever looking for the source of a weird behaviour.

  • 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!) Commented Mar 4, 2014 at 5:30

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.


I've been the sole committer on the TXR project, and have kept a detailed ChangeLog from quite early in the project. This is close to 11,000 lines long and growing: http://www.kylheku.com/cgit/txr/tree/ChangeLog

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

[2016 edit: as of the mid-2015, I no longer maintain a ChangeLog file; however, the commit messages are written in a format which conforms to Git and ChangeLog conventions at the same time. The same level of detail is there, in a way that doesn't cause merge problems. A ChangeLog file could be mechanically reconstructed from these comments.]

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 --hard (throw away these useless changes) 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.)

Here is a related question regarding the purpose of commit messages: Why Should I Write A Commit Message


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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.