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 "[e-mail]"

保持仓库中以 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 "[e-mail]"  

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上注册的公司邮箱，示例为：[e-mail].输入后请按[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://[e-mail]:29418/open/icec-cloud-job" && scp -p -P 29418 [e-mail]:hooks/commit-msg "icec-cloud-job/.git/hooks/"

## HTTP方式
git clone "http://[e-mail]: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://[e-mail]: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 提交不通过