SSG - Gitの統一標準

SSG - Gitの統一標準

17

6 分。

定義

SSG標準は、Gitのセマンティクス、アクセシビリティ、および動作ロジックに関する要件を規定しています。

構造とセマンティクス

1. 標準的なコミット - コミットの構造

コミットメッセージは、以下の構造で記述する必要があります:

<タイプ>([適用範囲]): <概要>

[コミット本文]

[フッター]

1.1. ヘッダー (Header) - 必須項目

タイプ (Type) - コミットの分類:

タイプ用途
feat新規機能
fixバグ修正
docsドキュメントの変更
styleロジックを伴わないスタイル変更
refactor新規機能を伴わないリファクタリング
perfパフォーマンスの向上
test (spec)テスト
chore補助的なタスク
buildビルド / 依存関係の変更
ciCI/CD スクリプト
revert前のコミットのロールバック

適用範囲 (Scope) - オプション。プロジェクトのどの部分が影響を受けるかを示します(例:uiapiauth)。例:

feat(api): ユーザー向けの新しいエンドポイントを追加

概要 (Description) - 変更内容を簡潔に記述します。命令形を使用することが推奨され、50文字以内とします。

1.2. 本文(Body)とフッター(Footer) - 任意のセクション

本文(Body) - 何が、なぜ変更されたのかを説明します。 フッター(Footer) は以下の目的で使用されます:

  • Breaking Changes:互換性のない変更は BREAKING CHANGE: または feat! で示します:

    例:feat!: 廃止されたAPIメソッドを削除しました

  • 課題(Issues)へのリンク:例:Closes #123

アクセシビリティ

2. 安全なコミットプロセスを実現するためのパイプラインの設定

パイプラインは、フォーマット、コミットの検証、および安全なブランチのマージを保証します。

2.1. 必要な依存関係

npm i -D \
  husky \
  lint-staged \
  @commitlint/cli \
  @commitlint/config-conventional \
  @commitlint/types \
  conventional-changelog-conventionalcommits \
  git-pull-run \
  @archoleat/commitlint-define-config

2.2. lint-staged の設定

lint-stagedは、インデックスに登録された変更のみをチェックします:

export default {
  '*': 'prettier --write',
  'src/**/*.{tsx,ts}': 'eslint --fix',
  'src/**/*.scss': 'stylelint --fix',
};

2.3. Commitlintの設定

Commitlintは、コミットの形式と許可されたタイプをチェックします:

import { defineConfig } from '@archoleat/commitlint-define-config';

export default defineConfig({
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [
      2,
      'always',
      [
        'build',
        'chore',
        'ci',
        'docs',
        'feat',
        'fix',
        'perf',
        'refactor',
        'revert',
        'spec',
        'style',
      ],
    ],
  },
});

defineConfig用のプラグインはこちらから確認できます

2.4. Gitフックの設定 (Husky)

フックコマンド用途
pre-commitnpm run lint-stagedコミット前のコードのフォーマットと修正
commit-msgnpm run commitlint --editConventional Commits への準拠チェック
post-mergenpm run git-pull-run --pattern 'package.json' --command 'npm i'マージ後の依存関係の自動インストール

Huskyのバグ:コミットがチェックに合格しない場合、変更内容が失われることがあります!

インタラクティブ性と視覚的な反応

3. コミットプロセスの概要

  1. 変更のステージング:
git add .
  1. コミットの作成:
git commit -m "feat(header): テーマ切り替えボタンを追加"
  1. pre-commit:
  • lint-stagedが実行されます;
  • Prettier、ESLint、Stylelintがステージングされたファイルのエラーを修正します;
  • 修正されたファイルが再度ステージングされます。
  1. commit-msg:
  • commitlintが実行されます;
  • コミットメッセージがConventional Commitsのルールに準拠しているかチェックされます。
  1. 結果:
  • すべてのチェックに合格した場合、コミットは正常に完了します。
  • フォーマットに違反している場合、エラーメッセージが表示され、コミットは拒否されます。
記事は随時更新されます

関連記事

  • SSF-U - フルスクリーン表示の統一規格

    SSF-U規格は、フルスクリーン表示のセマンティクス、アクセシビリティ、および動作ロジックに関する要件を規定しています

    23

    4 分。

  • SSA - アコーディオンの統一標準

    SSA規格は、アコーディオンのセマンティクス、アクセシビリティ、および動作ロジックに関する要件を定めています

    277

    5 分。

  • ウェブサイトにおける悪い慣行

    ウェブデザインにおける致命的なミスの分析。スライダー、自動再生、重いページがコンバージョン率やGoogle・Yandexでの検索順位を低下させる理由

    90

    2 分。

  • SSP - ページネーションの統一規格

    SSP規格は、ページネーションのセマンティクス、アクセシビリティ、および動作ロジックに関する要件を規定しています

    180

    3 分。

  • SSPS - プロジェクト構造の統一基準

    SSPS標準は、プロジェクト内のファイルおよびフォルダの構造と命名に関する要件を規定しています

    121

    3 分。

  • SSF-O - フォントの統一規格(Local、Google Fonts)

    SSF-O規格は、フォントのセマンティクス、アクセシビリティ、および動作ロジックに関する要件を規定しています

    16

    5 分。

  • すべての記事

プロジェクトの種類*