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中文路径名称乱码
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
动作后,会提示不符合规范,然后在控制台输出相应的提交规范说明
- 示例1:模拟命令行提交不通过
- 示例2:模拟
IDEA
提交不通过