I have compiled this information, including my own organisation.
Introduction.
Git requires a commit message when you commit.
It’s also an important indicator of what this commit is about, even when you’re developing a team. It’s also an important indicator that tells you what the commit is about at the beginning.
Commit messages are important for better development.
Also, if you try to commit without a commit message, the commit will be aborted.
# Please enter the commit message for your changes. Lines starting
# with ‘#’ will be ignored, and an empty message aborts the commit.
#
# On branch main
# Your branch is up to date with ‘origin/main’.
#
# Changes to be committed:
# new file: README.md
#
How to write Git commit messages
summarise the main points
It is usually summarised in about 30 words.
fix: Fixed error handling during login.Some people include a line break and elaborate on it, but we believe it is better to put that in the Description of the Pull Request.
Prefixing.
The Prefix makes the type of commit clear.
| Prefix | purpose |
|---|---|
feat | New features. |
fix | Bug Fixes. |
refactor | Refactoring (code improvement without functional change) |
style | Formatting corrections to the code (no impact on operation). |
docs | Document changes |
test | Adding or modifying tests |
chore | Build and library-related changes. |
feat: User login facility added.We have referred to Semantic Commit Messages here. It helps me to organise again. Thank you.
refs: https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716
Summary
Personally, I like to prefix commits because it increases the ease of review and makes it easier to take a hit when a bug occurs, for example, in an investigation.
In practice, you will probably commit several times before you create a single feature. Squash as appropriate to organise your commits. (You can also ‘Allow Squash Merge’ on GitHub.)
