Detailed and well-written commit messages can increase the value of Git revision history.
Every commit you make in Git also includes a commit message that explains the change. While one-line messages are fine for small or obvious changes, as your revision history grows, good commit messages become an important source of information — for example, to understand the rationale behind a specific change made in the past.
A commit message is meant to explain the intent behind the changes, not just what was changed. The code (or diff) already shows what changed. Well-written commit messages make collaboration, code reviews, debugging, and future maintenance easier by helping you and others quickly understand the project’s history without digging into the code of every commit.
A complete commit message can include a short summary line (the subject) followed by a more detailed body if needed. The subject line should be a concise description of the change, while the body can elaborate on the context, rationale, side effects, or other details if the change is more complex.
A commit message has the following structure (note how the subject and the body are separated by a blank line):
Subject line
<blank line>
Body
# lines starting with '#' are ignored (they will not be included in the commit message)
Here is an example commit message:
Find command: make matching case-insensitive
Find command is case-sensitive.
A case-insensitive find is more user-friendly because users cannot be
expected to remember the exact case of the keywords.
Let's,
* update the search algorithm to use case-insensitive matching
* add a script to migrate stress tests to the new format
Do some changes to a repo you have.
Commit the changes while writing a full commit message (i.e., subject + body).
When you are ready to commit, use the git commit
command (without specifying a commit message).
git commit
This will open your default text editor (like Vim, Nano, or VS Code). Write the commit message inside the editor.
Save and close the editor to create the commit.
You can write your full commit message in the textbox you have been using to write commit messages already.

done!
Following a style guide makes your commit messages more consistent and fit-for-purpose. Many teams adopt established guidelines. These style guides typically contain common conventions that Git users follow when writing commit messages. For example:
- Keep the subject line (the first line) under 50–72 characters.
- Write the subject in the imperative mood (e.g.,
Fix typo in README
rather thanFixed typo
orFixes typo
). - Leave a blank line between the subject and the body, if you include a body.
- Wrap the body at around 72 characters per line for readability.
PRO-TIP: Configure Git to use your preferred text editor
Git will use the default text editor when it needs you to write a commit message. However, Git can be configured to use a different text editor of your choice.
You can use the following command to set the Git's default text editor:
git config --global core.editor "<editor command>"
Some examples for <editor command>
Editor | Command to use |
---|---|
Vim (default) | vim |
Nano | nano |
VS Code | code --wait e.g., git config --global core.editor "code --wait" For this to work, your computer should already be configured to launch VS Code using the code command. See here to find how (refer the 'Launching from command line' section). |
Sublime Text | subl -n -w |
Atom | atom --wait |
Notepad++ | notepad++.exe (Windows only) |
Notepad | notepad (Windows built-in) |
Why use --wait
or -w
? Graphical editors (like VS Code or Sublime) start a separate process, which can take a few seconds. Without --wait
, Git may think editing is done before you actually write the message. --wait
makes Git pause until the editor window is closed.