チームが拡大を続けるにつれて、gitのコミット情報は、必要なときに使用しやすくするために、特定のフォーマット仕様に従う必要があります。情報を送信することで問題を簡単に特定できます。コードを確認すると、コミットの内容もわかっているため、コミットの標準化には多くの利点があるため、これ以上は述べません。
達成する
结合 git hook 实现在 git commit 阶段检查输入是否符合规范，符合通过，反之提示
ツール
commitlint：コミット情報の確認、「標準」、「分類」の定義
に使用されます。ハスキー：git-commitおよびgit-pushフェーズで使用されるフックツール
規範
commitlint-config-conventional（Angular規約に基づく）による一般的なタイプは次のとおりです。
build：プロジェクトのビルドシステム（xcodebuild、webpack、glutなど）の送信を
変更します。• ci：プロジェクトの継続的インテグレーションプロセス（Kenkins、Travisなど）を
変更します。送信日課：ビルドプロセスまたは補助ツールの変更•
docs：ドキュメントの送信（ドキュメント）
feat：新機能（機能）
修正：バグの修正•
実行：パフォーマンスとエクスペリエンスに関連するコミットの
リファクタリング：コードのリファクタリングの
復帰：以前のコミットのロールバック•
スタイル：プログラムのロジックに影響しないコードの変更、メインそれはスタイルの最適化と修正です
：テスト関連の開発
推奨されません
特定の送信の検証を無効にする場合は、パラメーター--no-verifyを追加できます。git commit --no-verify -m "xxx"
