日常の開発作業では、通常gitを使用してプロジェクトコードを管理します。コードを変更した後、gitcommitコマンドを使用してコードを送信できます。
Gitは、送信時に変更の説明として送信情報を書き込み、簡単に振り返ることができるようにコミット履歴に保存する必要があると規定しています。標準化されたログは、他の人がレビューするのに役立つだけでなく、CHANGELOGを効果的に出力でき、プロジェクトの研究開発の品質を大幅に向上させます。
しかし、日常業務では、ほとんどの学生がログ情報を書き込んだり書き込んだりするだけで、あまり注意を払っていないため、プロジェクトの管理や保守には間違いなく不向きです。この記事は主に、git commitのいくつかの仕様を共有するための私自身の経験に基づいているため、ログは「見栄えが良い」だけでなく「実用的」でもあります。
コミットメッセージを標準化する必要があるのはなぜですか？コミットメッセージ
の形式を標準化する必要があると言われているのに、なぜこれを行う必要があるのでしょうか。
最初に非標準のコミットレコードを見てみましょう：
それを読んだ後、どのように感じますか、最終的に更新されたもの、それはすべて書面による更新です、この種のコミット情報は間違いなくから効果的な情報を取得したい人のためのものですそれ。致命的な打撃。
次に、コミュニティでより人気のあるAngular仕様のコミットレコードを見てみましょう。
それを読んだ後、それは明らかですか？
上の図の標準化されたコミット情報は、最初にクイックブラウジングのためのより多くの履歴情報を提供します。次に、特定のコミット（ドキュメントの変更など）をフィルタリングして、情報の迅速な検索を容易にすることができます。
Angularチームの仕様がコミュニティで最も人気のあるコミット仕様になったので、正確には何ですか？それを詳しく見てみましょう。
Angularチームのコミット仕様と
そのメッセージ形式は次のとおりです。
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>コミットメッセージの3つの部分（ヘッダー、本文、フッター）に対応します。
ヘッダー
ヘッダー部分には、タイプ（必須）、スコープ（オプション）、およびサブジェクト（必須）の3つのフィールドを含む1行しかありません。
type：コミットのタイプを示すために使用されます。一般に、次のようなものがあり
ます。feat：新しい機能修正：バグドキュメントの修正：readme.mdstyleなどのドキュメントのみを変更します。コンマ、インデント、スペースなどの形式を変更するだけです。コードロジックを変更しないでください。リファクタリング：コードのリファクタリング、新機能やバグ修正はありませんパフォーマンス：パフォーマンスやユーザーエクスペリエンスの向上など、最適化に関連します。テスト：単体テストと統合テストを含むテストケース。雑用：ビルドプロセスを変更するか、依存ライブラリ、ツールなどを追加します。revert：バージョンロールバック
スコープ：コミットの影響のスコープを説明するために使用されます。たとえば、ビュー、コンポーネント、ユーティリティ、テスト...
件名：コミットの目的の簡単な説明
本文
の変更内容の具体的な説明コミット。これは複数の行に分割できます。以下に示すように：
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
# initial commitフッターには
いくつかの注意事項があります。通常、BREAKING CHANGE（現在のコードは以前のバージョンと互換性がありません）または修正されたバグへのリンク（問題を閉じる）です。
上記の仕様を簡単に紹介した後、git送信情報テンプレートであるcommit.templateについて説明しましょう。
git送信情報テンプレート
チームに送信情報の形式要件がある場合は、システム上にファイルを作成し、それをデフォルトテンプレートとして使用するようにgitを構成できます。これにより、送信情報を形式に準拠させることが容易になります。
次のコマンドを使用して、送信情報テンプレートを構成します。
git config commit.template [模板文件名] //这个命令只能设置当前分支的提交模板
git config — —global commit.template [模板文件名] //这个命令能设置全局的提交模板，注意global前面是两杠新しい.gitmessage.txt（テンプレートファイル）の内容は次のとおりです。
# headr: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore
# - scope: can be empty
# - subject: start with verb (such as 'change'), 50-character line
#
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# footer:
# - Include a link to the issue.
# - BREAKING CHANGE
#上記を読んだ後、私のように設定が面倒だと感じますか？あなたとあなたのチームに合ったほぼ完璧なコミット仕様を設定するのは簡単ではないようです。ただし、コミュニティでは、提出に役立ついくつかの補助ツールも提供されています。これらのツールを簡単に紹介しましょう。
commitizen
commitizenは、送信情報をインタラクティブに作成でき、修飾されたコミットメッセージを自動的に生成できるツールです。
インストール
-g commitizenインストールNPM
と使用
commitizenのinit CZ-従来-変更履歴--saveは--save-正確な
コミットプロジェクトに。
提出するときは、gitのCZを使用することができます。そして、あなたが自動化を生成することができます。画面の指示に従ってメッセージをコミット
するときCommitizenを使用して、最初に上下のキーを使用して、上記のfeat、fix、docs、perfなどに対応する必要なタイプを制御し、次にこの送信の影響を受けるファイルを選択して、書き込みを許可します短いものとは別に。そして詳細な提出の説明、そして最後に、この提出が重大な変更であるか、未解決の問題に関連しているかを判断できるようにします。最後に、その時点でのコミット履歴を表示すると、次のようなコミットメッセージが表示されます。
docs（docs）：READMEファイルを更新します
validate-commit-msg
commitizenは、独自のローカルコミットメッセージ仕様を保証できますが、チームメイトも標準化されることを保証できません。そのため、チームメイトの送信レコードが標準化されているかどうかを確認するには、他のツールが必要です。validate-commit-msgを使用して、チームメイトのコミットメッセージの仕様を確認します
安装
検証コミット-MSGハスキー-DインストールNPM
添加package.json文件配置
{ "フック"：{ "コミット-MSG"： "検証コミット-MSG"}} "ハスキー"
自定义校验格式を（可选）
追加一位.vcmrc文件、配置対象如下：
{"types"：["feat"、 "fix"、 "docs"、 "style"、 "refactor"、 "perf"、 "test"、 "build"、 " ci "、" chore "、" revert "]、" scope "：{" required "：false、" allowed "：[" "]、" validate "：false、" multiple "：false}、" warnOnFail "：false 、 "maxSubjectLength"：100、 "subjectPattern"： "。+"、 "subjectPatternErrorMsg"： "件名が件名パターンと一致しません！"、 "helpMessage"： ""、"自動修正"：偽}
提出
例：コミットgitの
-m'feat （main.jsを）：追加ルート」にCHANGELOGを生成する
従来、変更履歴インストール
-g従来-変更履歴-CLIをインストールNPM
＃CHANGELOG.mdを生成し、前のコンテンツを上書きします。conventional-changelog-p angle -i CHANGELOG.md -s -r 0＃リリースされたすべての変更ログを生成しますconventional-changelog -p angle -i CHANGELOG.md -w -r0
注
conventional- changelog -p angle -i CHANGELOG.md -wは、コマンドラインでCHANGELOGの内容のみをログに記録でき、ファイルは生成しません。ファイルを生成する場合は、conventional-changelog -p angle -iCHANGELOGを使用する必要があります。 md-s。従来のchangelog--help *を使用して、より多くの構成を表示できます。