git commit -m is a lie! How to commit like a pro
Tags: webdev, git, vscode, beginners
Published: 2024-06-10 22:21:30

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:

```bash
git commit -m "Fixed bug"
```

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:

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

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

```bash
git commit -m "Title" -m "Description"
```

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:

```bash
# 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"
```

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:

```bash
git commit
```

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

![Simple multi-line commit example](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/iglzhpg6h200ez2p9dud.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/flg5l9aq6mz657j5mu32.png)

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:

```bash
git config --global -e
```

Now, add the following alias to the file:

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

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

```bash
git ac
```

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:

```bash
[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
```

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.