Git Commit Message StyleGuide
TOC
About
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:
- Fun!
- 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
<subject>. - 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...").
- Use
<type>to identify what type of changes introduced in this commit; Allowed<type>keywords:- 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
- feat: new feature for the user(or
- 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.
- Use
<scope>to identify which component this<type>is related to; Example<scope>values:- init
- runner
- watcher
- config
- web-server
- proxy
- etc.
- The
<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.
Message Body
- 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.
Message Footer
- Reference issues this commit is related to with the status of that Issue; Ex.
Issue #27,Ref T27orRef T27, T56orFixes T8. - Supported issue tracker status keywords:
- Fixes
- Fixed
- Closes
- Closed
- Resolves
- Resolved
- Ref
- Issue
- Issues
- 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.
Notes
- Use valid MarkDown format in the
<body>. - All WIP(Work In Progress) commits SHOULD have the
�� Emoji. - All WIP commits SHOULD be avoided!.
- Referencing Issues by using special keywords like
FixesorResolveswill 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
<footer>. - Every emoji text(
:emoji:) is counted as one character!. - See ToDo Grammar StyleGuide for more Information on
@XXXComment Tags.
Suggested Emojis
| 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 @FIXMEComment Tag |
|
|
�� |
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 @CHANGED Comment Tag |
|
|
�� |
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 @REVIEW Comment Tag |
|
|
�� |
New Release |
|
|
�� |
New Release with Python egg |
|
|
�� |
New Release with Python wheel package |
|
|
�� |
Version Tags |
|
|
�� |
Initial Commit |
|
|
�� |
when Adding Logging |
|
|
�� |
when Reducing Logging |
|
|
✨ |
when introducing New Features |
|
|
⚡ |
when introducing Backward-InCompatible Features, maybe with @CHANGED Comment Tag |
|
|
�� |
New Idea, with @IDEA Comment Tag |
|
|
❄ |
changing Configuration, Usually together with
|
|
|
�� |
Customer requested application Customization, with @HACK Comment Tag |
|
|
�� |
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, ...) |
|
|
�� |
Docker Configuration |
|
|
�� |
when Merge files |
|
|
�� |
when Commit Arise from one or more Cherry-Pick Commit(s) |
Tools
- 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)
Contributing
To add a new Emoji to the list: Create an Issue & Send a PR.
License
The Code is licensed under the MIT License.
-
前言 我们都知道，Git 每次提交代码，都要写 Commit message（提交说明），否则就不允许提交，这其实就是规范，但输入的说明我们可以随便写。 无规矩不成方圆，当查看git提交历史的时候，发现每个人git的提交记录都有自己的风格和习惯，并没有一套完整的规范，不利于阅读和维护。所以需要一套git提交规范，使得提交记录清晰明了，让人一看就能知道此次提交的目的。 git commit -m "
-
背景 本文总结了项目实践中的 Commit Message 规范。 任何一笔提交都是有原因的，因此 commit message 需要说明该笔提交的 目的. 我们主要借鉴AngularJS Git Commit Message Conventions。 规范commit message想要达到的目的主要有： 提供更多更准确的信息。便于review，更容易发现潜在问题。便于查看历史记录回溯 发布版本
-
多人协作开发一个项目时，版本控制工具是少不了的，git是linux 内核开发时引入的一个优秀代码管理工具，利用它能很好使团队协作完成一个项目。为了规范团队的代码提交，也方便出版本时的release note，更为了出问题时方便代码回溯，所以大家统一用一个模板提交代码是必要的。Git中设置template非常简单，只需以下几步即可： 1、在根目录建立模板文件 如 xxx_template文件，其内容
-
背景 在使用git提交代码的时候，可能会出现message写错的状况， 若是此时commit已经push到远程服务器了， 修改起来就比较麻烦了。git 下面整理了一下，修改历史中某几回commit的message的通用办法。服务器 命令 如下修复方式中，总共涉及这些命令，spa $ git log $ git rebase -i HEAD~5 $ git commit --amend $ git
-
git rebase -i commit_old // -i 交互式 //commit_old 指的是要变更的commit的前一个commit 输入命令后会弹出两次编辑面板，这时候根据说明来就可以了
-
有些时候公司会要求git commit 强制附加jira链接，确定本次提交属于某个具体任务，提供下解决思路。 调研后决定使用husky实现，需要的插件 安装husky 安装commitlint # 安装husky npm install husky -D # 设置运行脚本并运行 npm set-script prepare "husky install" npm run prepare # 安装
-
上一篇文章记录了git中分支的删除以及出现分离头指针的情况，点击查看:【Git、GitHub、GitLab】七 git中分支的删除以及出现分离头指针的情况 1 如何修改最新的commit的message 使用下面的命令即可 git commit --amend –amend 不只是修改最新commit的message 而是会创建一个将暂存区的内容生成一个commit，再将当前最新的commit替换
-
1. 简述 关于 Git message 的写法规范社区中有很多种， 目前使用较为广泛的是 Angular 规范。 在 Angular 规范中， 每次提交， Commit message 都包括三个部分： Header、Body 和 Footer，下面进行详细介绍。 2. 格式介绍 <type>(<scope>):<subject> # header部分 // 空一行 <body> # bo
-
Git 修改 commit message 修改最近一次的commit 信息 git commit --amend 然后就会进入vim编辑模式 比如要修改的commit是倒数第三条，使用命令： git rebase -i HEAD~3 退出保存 :wq 执行 git rebase --continue 执行 git push -f 推送到服务端。 参考文章：博客园 - Git 修改commit m
-
问题 我们在提交git的时候，在每次提交之后都会追加当前提交的一些信息 比如： git commit -m"这是我第一次提交git" 在提交了本次修改之后，因为提交格式不对，你又想修改你上一次提交的git message信息，怎么办呢？ 解决 修改最近一次提交的message 修改上一次提交的message信息，我们可以使用以下命令： git commit --amend 然后会用vim或者vi
-
介绍 在 Git 中，每次提交代码，都要写 Commit message（提交说明），否则就不允许提交。这个操作将通过 git commit 完成。 git commit -m "hello world" 上面代码的-m参数，就是用来指定 commit mesage 的。 如果一行不够，可以只执行git commit，就会跳出文本编译器，让你写多行。 git commit 格式 Commit me
-
ngrx Style Guide Purpose The idea for this styleguide is to present commonly used techniques for working with ngrx suite and serve as a kind of a cookbook/recipes with a problem/solution theme. The pu
-
AngularJS styleguide (ES2015) Up-to-date with AngularJS 1.6 best practices. Architecture, file structure, components, one-way dataflow, lifecycle hooks. Want an example structure as reference? Check o
-
ember-styleguide This addon is intended to provide basic components for easier style coordination among the Ember family of websites, although the original intent is to support the emberjs.com website
-
规范建设 commit message格式 <type>(<scope>): <subject> type(必须) 用于说明git commit的类别，只允许使用下面的标识。 feat：新功能（feature）。 fix/to：修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。 fix：产生diff并自动修复此问题。适合于一次提交直接修复问题 to：只产生diff不自动修复此问题
-
Name git-commit - 记录对存储库的更改 概要 git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend] [--dry-run] [(-c | -C | --fixup | --squash) <commit>] [-F <file> | -m <msg>]