使用githook统一codestyle

Tech
,

gradle 优化

  • build 指定 -g cache 缓存

checkstyle 实践

  • 基础镜像包含 checkstyle.xml 或者 放到远程其他可被拉取到的存储介质 ，防止项目成员改动
  • gitlab-ci beforeScript 标签执行命令 copy /checkstyle.xml 进入项目，(覆盖项目中存在的).
  • gradle 编译的话 将 maven-publish.gradle repos.gradle checkstyle.gradle(checkstyle 插件配置 版本以及 configFile) 抽出放到公共的地方，防止项目团队成员改的.
  • maven 的话，可以在公共的顶级继承 pom 里面指定变量checkstyle.config.location. mvn checkstyle -Dcheckstyle.config.location=checkstyle.xml

git hook 实践

每个项目里面 .git/hooks 里面有很多的 hook 模板

客户端钩子包括:pre-commit、prepare-commit-msg、commit-msg、post-commit等，主要用于控制客户端git的提交工作流。

服务端钩子：pre-receive、post-receive、update，主要在服务端接收提交对象时、推送到服务器之前调用。

今天实践的是 客户端钩子，优化减少不符合规范或者低质量代码进入 gitflow 流程.

pre-commit 和 commit-msg 是今天的主角，pre-commit 执行与 git add 之后，在进行 git commit 之前进行的操作. 可以用来进行 code check code lint 等等, commit-msg 执行与 git commit 常用于补全 git commit message check msg 等等 当然还有其他骚操作的功能，可以通知，等等，做多种自动化

目录结构

project
- .git/..等等
- git_hooks
 -- pre-commit  # pre-commit action
 -- commit-msg  # commit-msg action
 -- init.sh     # 初始化脚本
  • pre-commit
#!/bin/bash
workPath=$(pwd)
CHECK_DIR=${workPath}/checks
if [ ! -d $CHECK_DIR ]
then
  mkdir $CHECK_DIR
fi
DOWNLOAD_PATH="http://{download.path}/checkstyle"
CONFIG_CHECK_JAR=$CHECK_DIR/checkstyle.jar;
CONFIG_CHECK_FILE=$CHECK_DIR/checkstyle.xml;
CONFIG_ERROR_FILE=$CHECK_DIR/checkstyle_errors.xml;
CONFIG_ERROR_REPORT_FILE=$CHECK_DIR/checkstyle_report.xml;

if [ ! -f $CONFIG_CHECK_JAR ]
then
  curl -o $CONFIG_CHECK_JAR $DOWNLOAD_PATH/checkstyle-8.8-all.jar || true;
fi

if [ ! -f $CONFIG_CHECK_FILE ]
then
  curl -o $CONFIG_CHECK_FILE $DOWNLOAD_PATH/checkstyle.xml || true;
fi

javafiles=`git diff --cached --name-only | grep '\.java'`;
echo $javafiles;

if [ -f $CONFIG_ERROR_FILE ]
then
  rm $CONFIG_ERROR_FILE;
fi

CHECK_CMD="java -cp $CONFIG_CHECK_JAR com.puppycrawl.tools.checkstyle.Main -c $CONFIG_CHECK_FILE $javafiles -f xml -o $CONFIG_ERROR_FILE";
echo "$CHECK_CMD";
$CHECK_CMD;

if [ -f $CONFIG_ERROR_FILE ]
then
    errorResponse=`cat $CONFIG_ERROR_FILE | grep \<error|head -n 1`;
    if [[ $errorResponse == *"error"* ]]
    then
      awk '{print;} NR == 1 { print "<?xml-stylesheet xmlns=\"http://www.w3.org/1999/xhtml\" href=\"checkstyle-simple.xsl\" type=\"text/xsl\"?>"}' $CONFIG_ERROR_FILE > $CONFIG_ERROR_REPORT_FILE;
      echo -e "Check your code. Open by Safari or Chrome ( --allow-file-access-from-files ): $CONFIG_ERROR_REPORT_FILE";
      open $CONFIG_ERROR_REPORT_FILE
      exit 1
    fi
fi

echo "check pass! pre_commit successfully!";
  • commit-msg
#!/bin/sh
# append CL message 信息（加入作者 例子）
#name=[PinkHello]
#commit="$name $(cat $1)"
#echo "$commit" > "$1"
echo $commit
commit=`cat $1`
echo "$commit" > "$1"
if [[ $commit =~ ^([A-Z]+)-([0-9]+):.*|(Merge.*)|(Revert.*)|(Other.*) ]]
then
  echo "commit successful!"
else
  echo "\033 Error: the commit message must start with JIRA ticket number \033"
  exit 1
fi
  • init.sh
#!/bin/sh
# 当前目录
workPath=$(pwd)
echo "当前初始化目录$workPath"
# 链接到 .git hooks 目录里面
ln -s -f $workPath/pre-commit $workPath/../.git/hooks/pre-commit
ln -s -f $workPath/commit-msg $workPath/../.git/hooks/commit-msg

echo "ln pre-commit commit-msg.....success."

google CR MR 规范

https://github.com/google/eng-practices

CL 规范：

  • 提交新的 subject ，才有祈使句，一个命令的形式言简意赅的表达这次要改变的什么，如需要详细上下文，关联 ticket，在 body 中说明
  • 简化 cl ，尽可能小，不要积攒一堆 change ，一次性提交，然后再一次性 MR ，加大了 review 风险。

MR 规范

  • 紧急 MR 适当放松
  • MR 不能带有脾气，目的是基于问题讨论，解决问题
  • 针对做的好的给予肯定和👍
  • LGTM means look good to me = 朕知道了！
  • MR 冲突，联系必要开发者一起参与决定避免出现代码丢失与错误.

CR 规范

  • 速度可以灭杀一切抱怨，不能让 cr 时间过长
  • CR 发现问题一定要让开发者去修改，不要有以后再修改的想法，这种方式往往是让系统变得更差的原因.
comments powered by Disqus