Git Commit Message StyleGuide
This is an attempt to standardize the format of commit messages, for the sake of uniformity in git log, best practices for writing commit messages & fun!
Using emojis at the beginning of commit messages, other than being fun, provides a simple way to indicate the intention of that commit, an ease for the eyes when browsing/reviewing git log. It’s also a simple measure of the fact that how much that commit is focused on a single purpose, which is a good practice.
If these rules and/or using emojis is an overkill for your productivity or simply losing its purposes, please tailor them to your needs or don’t use them.
Summary of the reasons for these conventions:
- Simple navigation through git history (e.g. ignoring style changes).
- Automatic generating of the changelog.
Commit Message Format
<type>(<scope>): <subject> <body> <footer>
Message Subject(first line)
- Capitalize the
- Do not end the first line with a period.
- Total characters of the first line MUST be Less than or Equal to 50 characters Long.
- Use the present tense (“Add feature” not “Added feature”).
- Use the imperative mood (“Move cursor to…” not “Moves cursor to…”).
<type>to identify what type of changes introduced in this commit; Allowed
- An Emoji(see below for list of Suggested Emojis)
- Or a Text:
- feat: new feature for the user(or emoji)
- fix: bug fix for the user(or emoji)
- docs: changes to the documentation(or emoji)
- style: formatting, missing semi colons, etc; no production code change(or emoji)
- refactor: refactoring production code, eg. renaming a variable(or emoji)
- test: adding missing tests, refactoring tests; no production code change(or emoji)
- chore: updating grunt tasks etc; no production code change
- If you need more than one keyword or emoji to use, you should probably think twice!. This usally means you need to break this commit into more smaller commits; If thats not the case then separate each emoji with a space.
<scope>to identify which component this
<type>is related to; Example
<scope>can also be empty (e.g. if the change is a global or difficult to assign to a single component), in which case the parentheses are omitted.
- Includes motivation for the change and contrasts with previous behavior.
- Use the body to explain whats and whys vs. hows.
- Wrap each line of the body at 72 characters.
- Reference issues this commit is related to with the status of that Issue; Ex.
Ref T27, T56or
- Supported issue tracker status keywords:
- More info on issue tracker status keywords:
- It’s also recommended to use Full URL to the Issues, instead of just issue ID Number; Doing so will ease browsing issues from terminal.
- In the case of multiple issues separate them with commas, Ex.
Closes #27, #56.
- Use valid MarkDown format in the
- All WIP(Work In Progress) commits SHOULD have the Emoji.
- All WIP commits SHOULD be avoided!.
- Referencing Issues by using special keywords like
Resolveswill mark them as closed automatically! For more information about automatic issue closing using ketwords see their documentation(linked above).
- There is NO new-line after the
- Every emoji text(
:emoji:) is counted as one character!.
- See ToDo Grammar StyleGuide for more Information on
|Emoji||Raw Emoji Code||Description|
||when improving the format/structure of the code|
||when creating a new file|
||when performing minor changes/fixing the code or language|
||when improving performance|
||when writing docs|
||when reporting a bug, with
||when fixing a bug|
||when fixing something on Linux|
||when fixing something on Mac OS|
||when fixing something on Windows|
||when removing code or files, maybe with
||when change file structure. Usually together with|
||when refactoring code|
||when adding tests|
||when adding code coverage|
||when fixing the CI build|
||when dealing with security|
||when upgrading dependencies|
||when downgrading dependencies|
||when forward-porting features from an older version/branch|
||when backporting features from a newer version/branch|
||when removing linter/strict/deprecation warnings|
||when improving UI/Cosmetic|
||when improving accessibility|
||when dealing with globalization/internationalization/i18n/g11n|
WIP(Work In Progress) Commits, maybe with
||New Release with Python egg|
||New Release with Python wheel package|
||when Adding Logging|
||when Reducing Logging|
||when introducing New Features|
||when introducing Backward-InCompatible Features, maybe with
||New Idea, with
||changing Configuration, Usually together with or or|
||Customer requested application Customization, with
||Anything related to Deployments/DevOps|
||PostgreSQL Database specific (Migrations, Scripts, Extensions, …)|
||MySQL Database specific (Migrations, Scripts, Extensions, …)|
||MongoDB Database specific (Migrations, Scripts, Extensions, …)|
||Generic Database specific (Migrations, Scripts, Extensions, …)|
||when Merge files|
||when Commit Arise from one or more Cherry-Pick Commit(s)|
- Commit(CLI): This is a nifty CLI tool to aid in standardizing commit messages based on this document, thanks to @jakeasmith.
- gitMoji(Firefox & Chrome Extension): Enhance your commits with emojis!, thanks to @louisgrasset.
Fun Emoji Usages
- CodeEmoji: Mozilla’s Codemoji enciphers your messages with emoji for fun and profit
- Emoji Based Diagram: Emoji Based Diagram of Data Bearing Subscription Updates(WebPush VAPID)
The Code is licensed under the MIT License.