大家所在的公司有 commit message 规范吗？

我见过不少写 1/2/3 的,瞎写

有，必须以 ticket 编号开头，并且会自动检查 ticket 状态，不符合的会拒绝 push

没有

之前公司必须 issue#taskNo: 提交信息这种

直接 squash merge，随便你怎么写 commit message 都不会显示在 master （

有什么自动检测提交是否合规的办法吗？（工具化）

我也很头疼有人 commit message 是“1” 、“up”这种。

@freebird1994 #4
bug 直接提在代码托管的 issue 里？

还真的有，这个很正常吧，统一的 message 有助于协作，尤其是合并的时候

commit mesage 没有，PR title 有。

这个很常见啊，一般用 Angular Commit Format 结合提交前检查，可以一定程度上约束。

@konakona hook 就可以实现，看这个 https://blog.ops-coffee.cn/s/xjlojmj9gtbfgnpwn_yu2a
介绍的事 svn 的 hook，git 的也一样有类似的

看看 github 的提交规范吧，我们公司就是这种，我觉得很合理

[XXX] XXXXXXXXXXXXX

@konakona 我们用的 svn-hook，大概是有个 xml 文件里有各种规范，提交时按这个 xml 检查，合规才接受提交。

有规范，commit message 中要关联 jira，不符合 push 会失败。

有规范的，不过没有做自动检查，全靠自觉

提交记录一堆 123456fixfixfix 能看么，要 git 干嘛。

@sfz97308 我怀疑你们用 jira

反正领导不看，那里面都是垃圾话，或者“今天真累啊，晚上去吃 xxx 吧” push!!

没有，因为不重视，很多人都只写 update

有，commit 前要新建事务卡片，卡片 id 不存在不能 commit

@gaoshiba 哈哈哈越看越馋的 History

有的，用 husky+gitlint 规范

[JIRA-ID|no-jira] (fix|feature|chore): do something

"no message"

可以在 svn server 里上 hook，自定义格式要求

有的代码格式不行都不让提交必须格式化

有的，我们是类别+项目+说明+CR，比如：bufix(account):fix account bind error 。http://gitlab.com/mergerequest/xxx

action(scope): short description

long description

Signed-off

什么叫「惊到」了，lint 很正常，没有 lint 也要遵守特定的成文规范，没有这些的公司 HR 是怎么招的人。

有的，要写任务编号，问题原因等等。。

这篇是我一直推荐阅读的：
https://chris.beams.io/posts/git-commit/

我司是自觉遵循 Angular 的 commit message 规范

各个 team 各个 team 的规范

没有，但是我尽量保证自己的 commit 符合一些通用规范

公司没有，自己定了一套，fix: xxxxx，feat: xxxxx，style: xxxxx

需要规范化
1. 有助于生成 CHANGELOG，及版本管理。
2. 有助于问题追溯，版本还原等

正确使用 git，代码规范算不算程序员的职业道德的一部分？

有规范，但不做强制检查

有配 commitlint

原团队比较规范，但也仅限于“提倡”。一些技术好的，也是直接一句“update”，看得我头疼。

后面也是三十多人的团队了，直到我离职前才有人负责做 git hook 来检查，最后还没推广出去，那人也离职了 hhhh

从来就没一家规范过。。。

@yolee599 我也是这样的，哈哈

这是我上周某天的 git 提交说明：

完成 备忘录相关功能与路由
修正 发布 text 日记时 resource 为空时的错误
添加 清单仅保存标题的逻辑
调整 清单数据按照添加时间升序排序
修正 非女性时获取不到另一半的记录
调整 resource 找不到资源时独立的错误
修正 保存头像时 avatar_preset 不能为空的问题
添加 清单记录软删除
移除 清单暂存功能（逻辑有冲突，移至本地保存）
添加 清单详情添加是否已经提醒字段
调整 保存提醒的具体时间
添加 清单提醒合作者
添加 检查某人情况完成状态
添加 提醒打卡的消息对象
添加 清单异常类
调整 日记筛选条件可以为逗号分隔的字符串
修正 时间戳中日期验证的格式错误
调整 纪念日可选时间区间

必须关联需求 id，形如 to #12345678: fix xxx

靠自觉

有，但没强制，我一般按规范来，毕竟方便回看，不过看到别人提交最多的是 temp，哈哈哈

idea 有模版插件，我们用的模版插件

必须要有

commit 没有，但是有想过通过命令行给 提交命令加 alias 的方式加上 ticket，一般都是描述干了啥

commit message 不是应该配着任务规划或者甘特图之类的写吗

如果有项目管理工具的话，以项目生成的 ID 开头

公司没有，但是自己会简单的写一下修复了啥啥啥 新增了啥啥啥 修改了禅道 bug 号多少多少
方便以后追溯问题

有 主要是前面要写好 jira 号码，后面随便写。 是服务器自动验证的。为了和 jira 整合

update
up
fix
up
xxxxxxx
up
:w
up up

有，但禁不住有人 「 fix: fix bug 」 系列提交
这些检测只是用于提醒对方忘了做什么事情，但是不能让有意想绕过的人修正自己的行为

@acrisliu

请问一下具体是如何实现拒绝 push 的？是用 pre-commit hook 吗？

@zhchbin #60 用 GitLab EE 自带的 Push Rules 。

https://docs.gitlab.com/ee/push_rules/push_rules.html#enabling-push-rules

前端有 commitlint

svn 有 hook，少一个冒号就不给提交
最近公司在切 git，看到有 hook 的脚本，没仔细研究原理，应该也有类似实现

[feature id] add / test function
1. xxx
2. xxx
or
[bug id] xxx

要求 commit message 必须有意义，版本迭代需要有规范的 changelog

git config --global commit.template 配置个模板，每次选填就完事了

我们这新来一小姑娘 commit 写 aaaaa 我说你 commit 不能写无意义的 message 不会写英文 中文的也可以(公司大佬之前要求 commit 都要用英文写) 结果人家写的是汉语拼音.....

必须有 icafe 单号，不然提不上去

一律: update

我都很规范的。title, summary, test plan 尤其 test plan 1 2 3 如何复现等等等等。commit msg 写的好基本就是文档。以后查起来很方便。别人紧急 revert 也不用把你半夜叫起来。我司倒是很少 aaa 的，太夸张了，至少有个 title. 我要是简单直接 request change

带 issue/ticket 号，必须有主谓宾

暂没有，现在还是写成:
1...
2...
3...
受以前 chrome 代码影响

我司一般有个前缀描述下提交的类型：

feat: 添加新特性
fix: 修复 bug
docs: 文档修改
style: 代码格式修改，空格、格式缩进等等，不改变代码逻辑
refactor: 代码重构
perf: 提高性能的代码更改
test: 增加或修改测试用例
chore: 其他修改，改变构建流程、或者增加依赖库、工具等

@mghio 哈哈，我们团队也是这样，感觉这东西只要团队成员统一一个规范就好

没有。除非出了问题，有人会在群里说一下：）

我为团队提交正规点，弄了个 idea 插件 Git Commit Message Helper 然后大家虽然格式规范了，但是提交消息的质量还是很差

必须要有

<feature> ...
<hotifx> ...
<refactor> ...
<test> ...
<doc> ...

有次查问题，去看了下另一个项目的提交记录，一眼望去，全是 update 和 fix，差点疯了。我每次提交写记录，rebase，有个啥用。

这个肯定有呀，参见 .git/hooks/commit-msg.sample 。至少用 Gerrit 的肯定会有一份本地的 commit-msg 生成 Change-Id 。

然后 Gerrit 上会检测 Jira key 、Jira issue status 、first line char num 、blank line then at least two line description…… 等等好多

@fordawn 得开发人员素质高啊

@sfz97308 老哥莫不是在菊厂哈哈

福报厂

没有，我一般用 emoji

@DiamondYuan 以前公司用华为云的代码托管,emoji 还会引起分支异常