Open Source Repository Commit Guidelines | Make Commit Messages Cuter

Reference: #

Introduction:#

Before anything else, if you are participating in team development, the standards should primarily be based on team requirements; this is mainly about maintaining your own repository.

Previously, I learned about basic commit messages, such as refactor, fix, feat, feature, perf, etc.

However, writing these felt unmotivating, and usually, when I couldn't think of what to write, I would just use update, update. As a result, the repository looked messy, and the git log was terrible.

Although Git Commit Messages can be described freely, using meaningless descriptions can have a huge impact on subsequent code reviews and understanding the purpose of the code. Therefore, having meaningful Commit Messages is the most basic requirement. Additionally, you should follow certain formatting standards, which can help everyone understand the details of the Commit more quickly and clearly. Here, I will mainly introduce the conventional Git Commit standards and Gitmoji standards, and finally, I will introduce some related configurations I commonly use.

Whether you have learned it before or not, you might as well try using this commit message standard as your repository standard; at least it feels more pleasant to write.

Showcase: https://github.com/yutto-dev/bilili

And my terribly messy repository looks like this: https://github.com/MrXnneHang/Blog

How to Do It:#

Modify the Last Commit Message:#

git commit --amend

This will open your last commit message, and you can modify it. I used to always reset --hard and then re-add when I made a mistake in a commit, and when files were modified, I had to back them up, which was a bit unfortunate, but I did this for six months.

Like this:

:memo: docs: copilot not working in vscode (This is the content of commit -m, :memo: is Gitmoji, it will automatically render after push)
# Please enter the commit message for your changes. Lines starting with '#' will be ignored, and an empty commit
# message will terminate the commit.
# ...

You can choose to modify your commit message here, then save and exit. Of course, you can also write it all at once during commit -m.

Additionally, the commit message is divided into three parts: header, body, footer. The specific writing method:

:memo: docs: copilot not working in vscode (This is the content of commit -m, :memo: is Gitmoji, it will automatically render after push)

This is the body part

This is the footer part
# Please enter the commit message for your changes. Lines starting with '#' will be ignored, and an empty commit
# message will terminate the commit.
# ...

The three parts are generally separated by blank lines. Finally, after you push to GitHub, you can click on the commit to see the detailed information of your commit message.

https://github.com/MrXnneHang/Blog/commit/17343e378c7e00dd971b5fd5209cb31faedb35f1

So when writing the header, it should be kept as short as possible, while detailed information can be placed in the body.

Custom Phrases:#

This greatly reduces the time I spend remembering and inputting Gitmoji.

For example, I can use ref to replace :recycle: refactor:

Most operating systems' default input methods support custom phrases; you can look for them carefully.

However, the last time I used the Sogou input method on Deepin, it caused garbled text, so unless necessary, it's better to add phrases to the default input method and then export a backup.

I have also added the above git commit --amend to my custom phrases.

Gitmoji and Git Message Correspondence Table:#

There may be some discrepancies.

In fact, using Gitmoji means you can skip using Git Message, but to prevent others from misunderstanding, it's better to include them.

Commonly used ones are:

🎉 init: Initialize
🚀 release: Release a new version
🎨 style: Code style changes (changes that do not affect code execution)
✨ feat: Add new features
🐛 fix: Fix bugs
📝 docs: Modify documentation
♻️ refactor: Code refactoring (neither adding new features nor fixing bugs)
⚡ perf: Code changes that improve performance
🧑‍💻 dx: Optimize developer experience
🔨 workflow: Workflow changes
🏷️ types: Type declaration modifications
🚧 wip: Work in progress
✅ test: Add and modify test cases
🔨 build: Changes affecting the build system or external dependencies
👷 ci: Changes to CI configuration files and scripts
❓ chore: Other modifications not involving source code and tests
⬆️ deps: Dependency modifications
🔖 release: Release a new version

You can send all of these to GPT, and it will give you its code, for example, this one I definitely use often: 💩 💩 bad code:

💩 and :poop: are equivalent; as long as you write it in the commit and push it to the repository, it will automatically render.

For a more complete view, check: https://nyakku.moe/posts/2018/09/16/git-commit-message-convention.html

You can add these one by one to your custom phrases, and then you can happily write commit messages.

I hope your future repositories are all lovely.