提交信息的格式
如何编写提交消息:(7条规则)
https://chris.beams.io/posts/git-commit/
参考:提交消息和更改日志编写指南:(格式)
http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html
提交信息的格式:
每次提交,提交消息都包括三个部分:Header标题,Body可选的正文 和 Footer可选的页脚。【类型:主题; 消息正文; 注释】
< type消息的类型>(< scope>): < subject主题>
type(必需):用于说明 commit 的类别,只允许使用下面7个标识之一。
- feat:新功能(feature)
Create write support
Add commit function
- fix:修补bug
Fix typo in introduction to user guide
修正用户指南简介中的打字错误
如果读者想知道错字是什么 简单地查看一下更改本身,即 git show或git diffor git log -p。
该 commit 的feat或fix将肯定出现在 Change log 之中
- docs:文档修改(documentation)
Update getting started documentation
更新入门文档
Update rakefile
Add todo file
Update readme
- style: 格式、分号或半冒号缺失等,代码无变动
- refactor:生产代码重构(即不是新增功能,也不是修改bug的代码变动)——重构是清理代码以使其更精简和更高效,并且在不影响代码的外部功能的情况下整体改进代码的设计。一些重构 Python 代码的好例子:https://docs.microsoft.com/en-us/visualstudio/python/refactoring-python-code?view=vs-2019
Refactor subsystem X for readability
重构子系统X以提高可读性
- test:测试添加、测试重构等,生产代码无变动
Merge branch ‘experiment’
Commit the todo
- chore:构建过程或辅助工具的变动:构建任务更新、程序包管理器配置等,生产代码无变动。
Remove deprecated methods
删除不推荐使用的方法
Release version 1.0.0
发行版本1.0.0
Update the footer to copyright information
将页脚更新为版权信息
由你决定,要不要放入 Change log,建议是不要。
scope(可选):用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。
subject(必需):是 commit 目的的简短描述,不超过50个字符。解释提交的作用(不是如何更改或为何更改!)
- 以动词开头,使用第一人称现在时,比如change,而不是changed或changes。 命令式语气
- 以大写字母开头且不以句号结尾
- 如果您很难进行汇总,则可能一次提交了太多更改。争取原子提交(单独发布的主题)。https://www.freshconsulting.com/atomic-commits/
// 空一行
分隔总结与主体的空行十分重要(除非你完全忽略主体);否则log
、 shortlog
和 rebase
等多个工具容易发生混淆。
< body可选>
任何一行都不得超过72个字符(或100个字符)。这是为了避免自动换行影响美观。 正文:解释一次提交的 **内容(与以前行为的对比)** 和 **原因(代码变动的动机)** ,而不是方式。并非所有提交都足够复杂到足以保证有一个正文,因此它是可选的,仅在提交需要一些说明和上下文时才使用。
- Git从不自动换行。在编写提交消息的正文时,必须注意其右边距,并手动换行。
- 建议使用72个字符,以便Git有足够的空间缩进文本,同时总体上将所有字符保持在80个字符以下。
- 一个好的文本编辑器可以为您提供帮助。配置Vim很容易,例如,在编写Git提交时将文本包装为72个字符。
-
- -要点也可以
-
- -使用悬挂缩进
- 解释该提交信息所解决的问题,说明你进行该变动的原因,而不是方法(代码本身可以解释方法)。该变动是否存在副作用或其他直觉性后果?
- 后续段落前需加空行。 可以列出要点 - 通常情况下,要点会使用空格加上连字符或星号,中间用空行分隔,但该规定存在差别。
// 空一行
< footer可选>
页脚是可选的,用于引用问题跟踪者ID。
提交消息示例
详见:https://udacity.github.io/git-styleguide/
> feat: Summarize changes in around 50 characters or less
>
> More detailed explanatory text, if necessary. Wrap it to about 72
> characters or so. In some contexts, the first line is treated as the
> subject of the commit and the rest of the text as the body. The
> blank line separating the summary from the body is critical (unless
> you omit the body entirely); various tools like `log`, `shortlog`
> and `rebase` can get confused if you run the two together.
>
> Explain the problem that this commit is solving. Focus on why you
> are making this change as opposed to how (the code explains that).
> Are there side effects or other unintuitive consequenses of this
> change? Here's the place to explain them.
>
> Further paragraphs come after blank lines.
>
> - Bullet points are okay, too
>
> - Typically a hyphen or asterisk is used for the bullet, preceded
> by a single space, with blank lines in between, but conventions
> vary here
>
> If you use an issue tracker, put references to them at the bottom,
> like this:
>
> Resolves: #123
> See also: #456, #789