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-nogerrit3、执行后，关上我的项目 .git/hooks 目录下的 commit-msg 文件，如果看到以下信息，阐明曾经胜利下载了commit-hook
示例
模仿一个不符合规范的提交，当执行 commit 动作后，会提醒不符合规范，而后在控制台输入相应的提交标准阐明
- 示例 1：模仿命令行提交不通过
- 示例 2：模仿
IDEA提交不通过