DEV Community

Cover image for git commit -m is a lie! How to commit like a pro
Andrew Shearer
Andrew Shearer

Posted on

git commit -m is a lie! How to commit like a pro

When you first started learning git, you probably learned that the way to commit something is by using git commit -m "your message". This is fine as a beginner, but once you start working in a professional environment, you'll quickly realize that using -m is insufficient. In this article, I'll cover some different ways to commit your changes, as well as some handy git tricks.

The -m flag is the most basic way to commit your changes. It's fine for small changes, but it's not very useful for larger commits. When you use -m, you're limited to a single line of text, which can make it difficult to explain what you're doing. For example, if you're fixing a bug, you might want to explain what the bug was and how you fixed it. With -m, you're limited to something like this:



git commit -m "Fixed bug"


Enter fullscreen mode Exit fullscreen mode

This is not ideal as it doesn't give much information. If you want to provide more information, you can use the -m flag multiple times:



git commit -m "Fixed bug" -m "The bug was caused by a missing semicolon"


Enter fullscreen mode Exit fullscreen mode

If you haven't seen this pattern before, you can think of it like this:



git commit -m "Title" -m "Description"


Enter fullscreen mode Exit fullscreen mode

Instead, what would be even better, is to to write a multi-line commit message. Doing this allows you to not only provide a title and description, but the ability to write a much more detailed description of why you made the changes that you did, and provide any other relevant information.

The simplest way of doing this is to configure your editor to be the default editor for git. Listed below, I've included a few examples of how to do this for some popular editors:



# For VS Code
git config --global core.editor "code --wait"

# For Sublime Text
git config --global core.editor "subl -n -w"

# For Vim
git config --global core.editor "vim"

# For Emacs
git config --global core.editor "emacs"


Enter fullscreen mode Exit fullscreen mode

Configuring your editor in this way not only provides you with the benefit of being able to write a more detailed commit message, but it also allows you to easily update your global git configuration file.

Now let's say it's time to commit something. Since you've configured your editor to be the default editor for git, now run the commit command without the -m flag:



git commit


Enter fullscreen mode Exit fullscreen mode

This will open up your editor, which for VS Code would look something like this:

Simple multi-line commit example

Something else to note is when you're working on a team, it's likely you'll be following a commit message convention. This is especially true when you're working on a project with multiple people with an issue / project management tool such as Jira. It's convention to start your commit message with the Jira ticket number, followed by a colon, and then the title of your commit. It would look something like this:

Multi-line commit with Jira ticket number

This is looking a lot better! Once you're done writing, save and close the file, and your changes will be committed.

But, why? Why would you want to commit changes like this? There are a few reasons:

  1. Clarity: Writing a multi-line commit message allows you to provide a clear and concise explanation of what you're doing. This is useful when you're working on a team, as it allows your teammates to quickly understand why you made the changes that you did. This is especially true when conducting code reviews on pull requests.

  2. History: When you write a detailed commit message, you're creating a history of your changes. This can be useful if you ever need to go back and see why you made a particular change.

  3. Documentation: A good commit message can serve as documentation for your code. If you ever need to go back and see why you made a particular change, you can look at the commit message to get a better understanding of what you were thinking at the time.

Another commit flag you may have used is -a. This flag is only semi-useful. The reason why I say that is that it will only commit previously tracked files. If you've created a new file as part of your current commit, you'll need to stage it first before using the -a flag. So, you'll need to use the add command for that.

With that in mind, I created a simple git alias for myself that will add all files to the staging area and then run the commit command without any flags. What is a git alias you may ask? A git alias is a way to create a shortcut for a git command, or a series of git commands.

To create a git alias, you'll need to add them to your global git configuration file. Since you've already configured your editor to be the default editor for git, you can run the following command to open up your global git configuration file:



git config --global -e


Enter fullscreen mode Exit fullscreen mode

Now, add the following alias to the file:



[alias]
  ac = !git add . && git commit


Enter fullscreen mode Exit fullscreen mode

Now, when you want to commit changes, you can run the following command:



git ac


Enter fullscreen mode Exit fullscreen mode

I use this alias all the time, and it's a nice little time saver. Here are some other git aliases that I've created for myself that you might find useful:



[alias]
  cg = !git config --global -e
  cpom = !git checkout main && git pull origin main
  mm = !git merge main
  ru = !git remote update
  dasm = !git branch | grep -v "main" | xargs git branch -D


Enter fullscreen mode Exit fullscreen mode

As a quick side note, if you're not sure what the last command is doing, it's deleting all local branches except for the main branch. This is useful if you're working on a project with a lot of branches and you're lazy like me and forget to delete them once they're merged into main.

I also created this extremely simple repo on GitHub that you can see the difference in the commits:

https://github.com/andrews1022/commit-example/commits/main/

I hope you found this article helpful! Let me know if you have any questions, or leave a comment if you have any other git tips and tricks you'd like to share.

Top comments (8)

Collapse
 
cerico profile image
cerico

Another approach to the -m problem is to go with semantic versioning prefixes, of fix, feat etc - and make an alias that prefixes your commits automatially by using the commit-msg-template

fix () {
    echo "#fix: $1" > ~/.config/git/commit-msg-template
    git commit
}
Enter fullscreen mode Exit fullscreen mode

This ensures all commits are properly prefixed (and you can set up another hook that prevents pull requests from having non-prefixed commits so there's no way they can sneak into the codebase

Collapse
 
algonzalez profile image
Al Gonzalez

Consider Conventional Commits. May be overkill for smaller projects but creates very nice blame details.

There is a VS Code extension, but I prefer creating a msg template like this

Collapse
 
danhof profile image
Daniel Hofman

Good info Andrew! I had no idea you can open an editor and save and commit a longer message. Starting with a Jira ticket number is my standard practice so this is helpful.

I created an app for that:) Try CommandGit.com GUI on Windows. You can setup a button with all your commands and insert user input that can capture bug# or a multi line message as you execute the command. Use it all the time myself.

Collapse
 
mtancoigne profile image
Manuel Tancoigne

Thank you for the configuration details.

I'd better use git add --patch (or git add -p) instead of git add .: it allows to select only the changes you want to stage before committing and is, for me, a good way to review my changes and avoid adding non-atomic changes.

Collapse
 
mdrijwan profile image
Md Rijwan Razzaq Matin

this is quite unnecessary really. the most popular way is to use conventional commits. you should try it!

Collapse
 
andrews1022 profile image
Andrew Shearer

I think saying "this is quite unnecessary" is a bit harsh, tbh. I was not aware of Conventional Commits, as we (the team I'm on) don't use it, and we don't really enforce any patterns other than prefixing the commit title with the Jira ticket number. That being said, I will certainly keep CC in mind!

Collapse
 
mdrijwan profile image
Md Rijwan Razzaq Matin • Edited

Then you have more reasons to use conventional commits and once you do, youโ€™ll realize how useful it can be.

Sorry if it seemed harsh to you as that wasnโ€™t the intention at all. Perhaps itโ€™s a forced habit of reviewing PR to keep it brutally honest ๐Ÿ˜…

Happy coding ๐Ÿ˜

Collapse
 
itsfarhankhan28 profile image
FARHAN KHAN

There is another command to make a organized commit that is 'czg'
Can you please explain the difference in using the 'czg' command and making the code editor a default git editor?