git配置以及替换gerrit默认commit-msg hook
记得要微笑 -Git 配置规范配置用户名和邮件
为了提交记录便于识别,配置中文名,邮箱配置成gitlab
注册邮箱
git config --global user.name "中文姓名"
git config --global user.email "email@[email.com"
示例
user.name
配置规则: name#工号
示例 git config --global user.name "张三#A00003"
user.email
配置规则: 统一使用公司的邮箱。示例 git config --global user.email "san.zhang@casstime.com"
LF
换行git config --global core.autocrlf input // 因为linux服务默认使用LF作为换行符格式
参考资料:git core.autocrlf配置说明
git中文路径名称乱码git config --global gui.encoding utf-8
git config --global core.quotepath false
让git mergetool
不再生成烦人的备份文件(*.orig
)git config --global mergetool.keepBackup false
让文件名区分大小写git config --global core.ignorecase false
不修改文件模式(文件mode变化不提交到仓库)git config --add --global core.filemode false
文件重命名不生效(大小写不敏感)时,请使用 git mv
重命名git mv lineConfig.js LineConfig.js
为了方便您的配置,您可以直接运行以下脚本git_config_default.sh
# git_config_default.sh
# 配置用户名和邮件
# 为了提交记录便于识别,配置中文名,邮箱配置成gitlab注册邮箱
# user.name 配置规则: name#工号 示例 git config --global user.name "谭智军#A00015"
# user.email 配置规则: 统一使用公司的邮箱。示例 git config --global user.email "zhijun.tan@casstime.com"
read -p "请输入您的姓名和工号,示例为:王永林#A00514.输入后请按[enter]键结束。" USER_NAME
git config --global user.name "$USER_NAME"
echo "设置后 user.name 值为 "
git config user.name
# TODO user.name 符合正则 [\u4e00-\u9fa5]{2,}#[A-B]\d{5} 才可以继续输入
read -p "请输入您在gitlab上注册的公司邮箱,示例为:yonglin.wang@casstime.com.输入后请按[enter]键结束。" USER_EMAIL
git config --global user.email "$USER_EMAIL"
echo "设置后 user.email 值为 "
git config user.email
#保持仓库中以 LF 换行
git config --global core.autocrlf input
echo "git config --global core.autocrlf input"
#git中文路径名称乱码
git config --global gui.encoding utf-8
git config --global core.quotepath false
echo "git config --global gui.encoding utf-8"
echo "git config --global core.quotepath false"
#让git mergetool不再生成烦人的备份文件(*.orig)
git config --global mergetool.keepBackup false
echo "git config --global mergetool.keepBackup false"
#让文件名区分大小写
git config --global core.ignorecase false
echo "git config --global core.ignorecase false"
#不修改文件模式(文件mode变化不提交到仓库)
git config --add --global core.filemode false
echo "git config --add --global core.filemode false"
使用方式如下:
Windows
第一步:把git_config_default.sh
另存到指定的系统目录下;
第二步:在该目录右键 选择【Git Bash Here】进入Git命令行界面;
第三步:输入以下命令
chmod 777 git_config_default.sh
./git_config_default.sh // 执行git_config_default.sh脚本
执行示例如下:
Mac
第一步:把git_config_default.sh
另存到指定的系统目录下;
第二步:在该目录右键 选择【进入终端】进入Git
命令行界面;
第三步:输入以下命令
chmod 777 git_config_default.sh
./git_config_default.sh
示例如下:
Git 提交规范目的git commit
信息作为一个基础的交互窗口,既可以快速确定提交影响、关联设计文档、关联缺陷bug
单、后续还能对项目或团队工作进行溯源改进。
git commit
信息的规范化,既体现开发同学的专业素养,也属于公司的过程资产,因此对git commit
提交的规范设计如下。
在commit
提交规范中,明确本次提交格式
【提交类型】
明确 一次代码提交的目的。要么是新增功能(feat
),要么是修复bug
(fix
),再者依赖、构建、配置升级、测试代码等等(other
)。
【提交说明】
明确提交目的后,我们还需要看看具体内容。通过关键字描述提交详情,更明确的传递提交的价值。
【相关链接】
方便支持接口设计、story
设计、需求、bug
描述等不同类型代码提交的需求,我们同时支持JIRA
、confluence
链接。
为了方便使用,我们采用Angular
规范,如下:
git提交规范
规范说明
提交类型(必须):
feat(新增功能)
fix(修复bug)
other(依赖,构建、CI、格式等,可通过提交信息说明)
提交说明 (必须):描述此次提交所修改的内容(长度限制2~100, 约定说明中不要包含"[]", 会影响校验规则)
相关链接 (必须):Jira 链接或 Confluence 链接
规范格式
提交类型: 提交说明 [相关链接]
提交示例
feat: git提交规范说明 [https://jira.casstime.com/EC0001]
关于规范的常见问题
问题1:story
编写或者发布阶段没有jira
,强制jira
编号的不知道如何填写,只能提前创建Jira
针对这个问题,我们和开发同学进行了沟通,我们把之前强制要求填写jira
编号 改成了强制要求填写相关链接,这样在story
设计阶段可以填写 story
的confluence
地址, 发布阶段可填写checklist
地址。
问题2:提交类型太少,不知道如何选择,比如说以下场景,修改ci
, 正式版本打包,调整代码格式,代码重构,性能优化等等
针对这个问题 ,我们还是坚持不增加新的类型,但是把原来的refactor
修改为other
。
一个原因为了约束提交时的代码完整性,我们推荐的是一次提交对应的一个具体的story
功能,不推荐一个功能出现多次提交的情况 ,如果类型给的太多,那么我随意修改一次代码的时候,就可以有对应的类型来选择,代码完整性上就没有约束性。另一个原因也是越简单越容易理解,每个人都有自己的理解,比如说,我修改了一个pom
的版本重新打包,但是现在类型有 ci
和 build
,那这个场景该如何选择,相信有人会认为是ci
,也有人会认为是build
针对代码重构,性能优化这2个场景没有类型,从迭代的角度说,这2个场景也是属于增加新功能或者修复bug
,因为做2个任务的时候,肯定是需要对应的story
或jira
来跟踪。 可能确实会存在一些场景需要特殊调整,但是一般这种场景都是低频的,选择other
,加上对应的描述即可,大家也可以理解为符合angular
提交的那些类型现在变成了子类型,只是说这个子类型是放到了描述当中
此节主要是描述现有工程项目如何集成commit-msg hook
对Commit
信息进行验证。初步想法是利用git
的hooks
来进行验证,当执行git commit
命令后,便会自动触发此hook
,然后对提交的commit
信息进行格式的验证。
小提示
Git Hook
大致分为两种,一个在服务端,一种放在本地。其中,本地的 hook
不受版本控制器的管理,也就是说我们没办法把写好的 hook
脚本放在.git/hooks
下面,然后推送到仓库,供小伙伴们下载、使用(除非自己将hook
文件手动复制到项目的./git/hooks
目录下)
经过对gerrit
代码审核平台的分析,我们已经解决了需要开发同学手动执行命令下载commit-hooks
的问题,对如何解决这个问题的同学可参考下面:
gerrit
如何替换默认的commit-hook
文件
如何集成我们自定义hook
进行提交信息检查上,并且让开发同学什么都不用做便可获取到我们提供的规范检查hooks
?起初遇到了很多问题,命令行、插件方式都进行过尝试,但是都没有很好的解决这个问题,还是需要开发同学手动执行才行,为了很好的解决这个问题,
我们首先在gerrit
代码审核平台上clone
一个工程的命令:
clone工程命令
## SSH方式
git clone "ssh://a00514@gerrit.casstime.net:29418/open/icec-cloud-job" && scp -p -P 29418 a00514@gerrit.casstime.net:hooks/commit-msg "icec-cloud-job/.git/hooks/"
## HTTP方式
git clone "http://a00514@gerrit.casstime.net:8087/a/open/icec-cloud-job" && (cd "icec-cloud-job" && mkdir -p .git/hooks && curl -Lo `git rev-parse --git-dir`/hooks/commit-msg http://a00514@gerrit.casstime.net:8087/tools/hooks/commit-msg; chmod +x `git rev-parse --git-dir`/hooks/commit-msg)
## ANONYMOUS HTTP方式
git clone "http://gerrit.casstime.net:8087/open/icec-cloud-job" && (cd "icec-cloud-job" && mkdir -p .git/hooks && curl -Lo `git rev-parse --git-dir`/hooks/commit-msg http://gerrit.casstime.net:8087/tools/hooks/commit-msg; chmod +x `git rev-parse --git-dir`/hooks/commit-msg)
可以看到,命令被分为了2个部分,一个部分是执行clone
代码操作, 一个部分是执行下载gerrit
提供hooks
操作,由此可知,gerrit
是提供了默认的commit-hook
文件的,我们只要对其进行替换即可。
基于以上的分析,我们做了以下的操作步骤
注:文档中的lib
位置是错误的,真正需要替换是截图中的lib
包,替换完成重启既可, 不需要执行初始化等步骤操作步骤小提示 (前端开发同学注意)
git
提交规范试行的过程中,前端工程的好像是集成了一个husky
插件,覆盖了工程.git/hooks
下的文件,针对这个情况,前端这边的工程,由SE
自己决定是继续使用 husky
插件 或者 使用我们推荐的方式
1、如果是还未clone
的工程,正常clone
工程即可,其它的什么都不用做,我们已经替换了gerrit
默认的commi-hook
文件,校验文件会随clone
命令自动克隆到工程的.git/hooks
目录下。
2、如果是在git
提交规范规范推行之前已经clone
到了本地的工程,则需要自己手动执行命令下载commit-hook
,命令如下
hook下载命令
# 如果clone的项目是gerrit项目,则执行此命令
curl -Lo .git/hooks/commit-msg http://10.2.43.24:3311/commit-msg
# 如果clone的项目是gitlab项目,则执行此命令
curl -Lo .git/hooks/commit-msg http://10.2.43.24:3311/commit-msg-nogerrit
3、执行后,打开项目.git/hooks
目录下的commit-msg
文件,如果看到以下信息,说明已经成功下载了commit-hook
模拟一个不符合规范的提交,当执行commit
动作后,会提示不符合规范,然后在控制台输出相应的提交规范说明
IDEA
提交不通过