From the course: Complete Guide to Git

Write commit message - Git Tutorial

From the course: Complete Guide to Git

Start my 1-month free trial Buy for my team

Write commit message

“

- [Instructor] In the previous movie, we made our first commit and provided a description to go with it. In this movie, I'll give you some tips on writing good commit messages because there are some best practices. The first and most important is to always include a short single line summary that's less than 50 characters long. It's totally fine to only provide that single line summary, and in fact, on most of my commits, that's what I do. But if you want to provide more detail, then you can add a blank line and then write a longer description that can take up multiple lines. It's a good idea to keep each line to less than 72 characters just because we can't know for sure what device will be used to view it and 72 characters is a widely supported width. I also recommend writing your commit messages in the present tense, not in the past tense. So you might use "Fix for a bug" or "Fixes a bug", but not "Fixed a bug". It makes sense if you stop and think about it. This is not a log of your personal activity as a developer. This is a label that's on a set of changes. It's not the biggest deal in the world if you get it wrong sometimes, but it is a best practice. If the changes are related to a change request or a bug report that has a tracking number, it might be useful to include that in the commit message, or your organization may have a preferred style or a shorthand to use in commit messages. For example, each commit might start with the types of things that are being changed. It might start with the word like feature or bug fix, or it might start with a tracking number from a support ticket. The key is to be clear and descriptive. Let me give you a couple of examples of what I consider bad and good messages. Bad would be just to say fix typo. Better would be to say that it adds a missing hyphen in the project section. Bad would be just to say it updates the login code. We don't really know what was done, but a better message would say it changes the user authentication to use Blowfish. And you also don't need to include any extra commentary. Just describe the changes that are being made. In this example, "Updates member report" is fine, but "We should discuss if this is the best approach next week", that's just additional commentary, and this is a label that will live on far past next week, and it won't be useful to have that commentary going forward. Let me give you an example of what a good multi-line commit message might look like. You can see that we have a tracking number at the beginning of the first line and then a hyphen, and then a short, simple description. Now that's not very descriptive of what's being done, but we do have the longer description that lets us know exactly why the commit was made and what changes are inside this set. Some of these best practices may feel a little bit weird at first, but I think you'll get used to them and find them useful over time.

Contents