gitが検証仕様を提出し、自動的にログファイルを生成する方法

gitが情報を提出するたびに、提出されたフォーマットが仕様に合っているかどうかを確認し、eslintを実行します。
両者が一致してから正常に提出できます。提出した情報に基づいて自動的にログ情報を生成することができます。
一般的にはアングラーCommt Messageに従う。
comitフォーマットを検証します
comitが仕様に合っているかどうかを確認します。一般的にグローバルにインストールできますか？それともローカルにインストールできますか？
install
全体

npm install -g @commitlint/cli @commitlint/config-conventional

ローカル

npm install --save-dev @commitlint/cli @commitlint/config-conventional

グローバルであれば、以下のコマンドを使用して全体を確認します。インストールが成功していますか？

npm ls -g -depth=0

プロファイルを生成
プロジェクトルートディレクトリで以下のコマンドを実行して対応するプロファイルを生成します。

touch commitlint.config.js

ファイルの内容は主に以下のように設定できます。

module.exports = {
 extends: ['@commitlint/config-conventional'],
 rules: {
 'type-enum': [2, 'always', [
  "feat", "fix", "docs", "style", "refactor", "test", "chore", "revert"
 ]],
 'subject-full-stop': [0, 'never'],
 'subject-case': [0, 'never']
 }
};

husky
一般的な検査規則が設定されたらhuskyが提供したフックと結合して、comitの前に先にチェックします。もし検査規則に合わないなら、失敗を提出します。
huskyはgitのフックを全部受け継いでいます。huskyを使う前に、git initを使ってください。でないと、gitファイルは、gitのフックを継承することができません。
プロジェクトから削除した場合、gitファイルは、git initの後にhuskyを再インストールする必要があります。そうでなければworkではありません。
install

npm install husky --save-dev

 
config
package.jsonに配置を追加します。

"husky": {
 "hooks": {
  "commit-msg": "commitlint -e $GIT_PARAMS"
 }
 }

これまでは、毎回提出しても仕様に合わないと失敗します。以下のような提示があります。


comitizen
補助的なツールは、私たちに標準的なcomit情報を書かせてくれます。
インタラクティブコマンドによって、私たちは規範に合ったcomitを書くことができます。全体的にインストールできます。
install

npm install -g commitizen

インストール後、git comitが必要なところでgit czを使って代用すると、対話式コマンドラインのウィンドウが現れます。直接に対応するオプションを選択して記入してください。
以下のとおりです


lint-staged
このツールは提出とあまり関係がないようですが、一般的にも使われますので、ここでちなみにこれは提出するたびに、今回変更されたコードだけをeslintに検証させます。他のコードに対してはlintには行きません。
毎回提出するとすべての書類に対してなるとは限りません。
install

npm i --save-dev lint-staged 

config
package.jsonに配置する：

 "husky": {
 "hooks": {
  "pre-commit": "lint-staged",
  "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
 }
 }

もちろんここであなたのプロジェクトの中でeslintに関する他の構成は近く配置されていると仮定します。prettierrcを加えてコードをフォーマットすることもできます。ここでは追加しません。
上の配置は提出する前に変更されたコードをリントします。
ログファイルを自動生成
主にconventional-changeツールを使って、私達が自動的にログファイルを作成するのを手伝ってくれます。
install
一般的にこのようなツールは全体的にインストールできるので便利です。

npm install -g conventional-changelog

上の運転関連命令だけをインストールするとエラーが発生します。対応するcliをインストールします。

npm install -g conventional-changelog-cli

以下のコマンドを使ってインストールが成功したか確認できます。

npm ls -g -depth=0

自動生成ログ
大丈夫です。次のコマンドはプロジェクトのルートディレクトリで実行します。

conventional-changelog -p angular -i Changelog.md -s

もちろん、package.jsonにコマンドを配置することもできます。これはとても便利です。

"scripts": {
 "changelog": "conventional-changelog -p angular -i Changelog.md -s"
 },

このように、次のコマンドを実行するたびに、プロジェクトのルートディレクトリに自動的に対応するログファイルを生成できます。

npm run changelog

もちろん上述のchangeog.mdは生成されたファイル名です。あなたも自分の望むファイル名にすることができます。

締め括りをつける
この道具を使って間違いやすいところをいくつかまとめましょう。
1.huskyを使う前にgit initを必要とします。プロジェクトの中のgitフォルダを削除すると、huskyが近くにインストールされていますが、git initを再構築した後もhuskyを再インストールしなければなりません。そうでなければ、gitのフックは継承できません。workではありません。
2.上記の第一条に対して、ある時はコースによって来ますが、このエラーを報告することがあります。
この時、ローカルプロジェクトの中を確認できます。git有木有hooksファイルがあります。もしhuskyがgitを継承していないと説明していません。あれば、rm-rf.git/hook sにして、huskyを再インストールします。これはclosed issueです。

3、ログを生成する時もconventtional-change-cliをインストールしなければいけません。命令で見つけられないエラーを報告します。
ここでgitについて検証規範を提出して、自動的にログファイルを作成した文章を紹介します。より多くの関連gitは検証規範の内容を提出します。私達の以前の文章を検索したり、下記の関連記事を引き続き閲覧してください。これからもよろしくお願いします。