场景：Git 提交次数较多，为了便于检索，我仍希望在提交信息内写入一些有意义的线索关键词。但我不想要提交时每次重复输入 bugfix、remove、update 等单词。于是我拟定了一份语义化的单符号规范表： ASCII 单字符(符号) 含义 + 添加功能、模块、特性等内容 - 删除功能、模块、特性等内容 ! BUG 修复、关键性改动 ^ 仅依赖库升级 . 相关内容完善、微不足道的小修改符号跟一个空格后可写上相关关键词，例如这些 commit message ： + buy module ! no refresh bug . 不知道开发社区上是否有过类似的单符号规范表？你还有什么喜欢用或值得推荐的 ASCII 单符号？

一个字符的 Git 提交信息公约？

LittleboyHarry

场景：Git 提交次数较多，为了便于检索，我仍希望在提交信息内写入一些有意义的线索关键词。但我不想要提交时每次重复输入 bugfix、remove、update 等单词。于是我拟定了一份语义化的单符号规范表：

ASCII 单字符(符号)	含义
+	添加功能、模块、特性等内容
-	删除功能、模块、特性等内容
!	BUG 修复、关键性改动
^	仅依赖库升级
.	相关内容完善、微不足道的小修改

符号跟一个空格后可写上相关关键词，例如这些 commit message：

+ buy module
! no refresh bug
.

不知道开发社区上是否有过类似的单符号规范表？你还有什么喜欢用或值得推荐的 ASCII 单符号？

Kael4

LittleboyHarry 但我不想要提交时每次重复输入 bugfix、remove、update 等单词。

如果只是为了减少输入bugfix, feat这些单词的输入次数，何不写一个脚本

LittleboyHarry git log --oneline 时列表每行开头一个字符能很好地对齐显示，一目了然

这个学习成本感觉还是比较大的，而且如果别的公司/组织改了其中一个的语义，那理解代价还是挺大的。没有一个统一的标准。真要用的话倒不如用缩写F: feat f: fix bf: bugfix

0x0001

在想类似 + 和 - 这样的符号，会不会和一些搜索过滤的语法产生冲突，然后偏离了预期

LittleboyHarry

0x0001 一般用 grep，如 grep -E '^\+' 转义字符，感觉不算太复杂。可以记下自动脚本

提交时输入麻烦与搜索时输入麻烦，看个人或团队取舍吧

LittleboyHarry

git log --oneline 时列表每行开头一个字符能很好地对齐显示，一目了然

hsxfjames

我认为这是牺牲可读性的偷懒。

有记忆成本
不直观，不容易理解，不利于快速阅读
新人上手困难
语义过少
可能会与随后的提交信息产生歧义

事实上如果真有什么大改动，好好打注释和提交信息所花费的时间与开发工作量相比九牛一毛。而良好的文档记录有利于追溯和后人理解。

这是著名前端库 React 的其中一些提交记录。
可以看到除了主要的提交信息外，还写了一大段说明来表达问题的背景、解决的思路等，而这些信息都可以在 git log 和 git blame 的时候体现，当你未来发现某处实现有问题或者不理解为什么这么做，可以直接看到当初的设计思路。

一般来说，大的项目并不一定要求你必须写这么长的提交说明，但主要的提交信息还是得好好写吧。

LittleboyHarry

hsxfjames @MikyMing

理想情况下确实提交信息描述越细越好。但在赶工期、加班push的项目中，我们有必要花很多时间精，把每次提交信息写得一清二白吗？做不到。但又为了避免没有信息留作线索，我想需要一种妥协。

“好好写”“看起来良好”“有可读性”只是一种仁者见仁的主观感受。毕竟团队里总有审美特异的人觉得“我赶着6日活动节吃中午饭，一个小时赶出来bug多多的查询接口模块”也是一句重要的话，可谓众口难调

所以我想在提交信息上是否存在一些基本的共识与公约，易于实践和交流？例如提到的语义化“单字符符号表”

它对提交创作者是易于判断的：是否有添加、删减功能？是否修复了 bug？

它对于提交阅读者是语义化（可检索的、规范的）、明确无歧义的。

hsxfjames

配套 CR 机制则没有妥协，再怎么 push 怎么赶也得好好写，不修不通过。“你说你项目紧？那你写这么多 bug 等 QA 帮你修吗？还不赶快把它搞好”。

而如果没有专门做 CR 、做规范的团队，怎么达成统一用一套提交规范的共识，我认为有点难以实现。只要它不是一个强制的，我就可以今天“+ 实现一个模块”，明天“feat: 提交”，后天“+ 修复问题”“. 修复问题”，看着貌似 80% 都符合所谓的公约了，其实剩下 20% 是随心所欲的，而 80% 中的 80% 可能又是没按语义规定走的。