SSG - Single Standard for Git

Definitions

The SSG standard defines requirements for the semantics, accessibility, and logic of Git.

Conventional Commits - Commit Structure

A commit message should be structured as follows:

<type>([scope]): <brief description>

[Commit body]

[Footer(s)]

Header - Required Section

Type - commit classification:

Scope is optional and indicates the affected part of the project (e.g., ui, api, auth):

feat(api): Added a new endpoint for users

Description describes the changes, preferably in the imperative mood, no more than 50 characters.

Body and Footer, Optional Sections

Body explains what has been changed and why.

The footer is used for Breaking Changes, incompatible changes are indicated with BREAKING CHANGE: or feat!, for example, feat!: deprecated api methods removed, as well as for links to issues, such as Closes #123.

Setting Up the Pipeline for a Safe Commit Process

The pipeline handles formatting, commit validation, and safe branch merging.

Required Dependencies

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

Lint-staged Configuration

Lint-staged checks only staged changes:

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

Commitlint Configuration

Commitlint checks commit formatting and allowed types:

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',
      ],
    ],
  },
});

You can view the defineConfig plugin here

Configuring Git Hooks (Husky)

There is a bug in Husky where, if a commit fails validation, changes may sometimes be lost!

The Final Commit Process

• Staging changes:

  git add .
  

• Creating a commit:

  git commit -m "feat(header): added theme toggle button"
  

• pre-commit:

  lint-staged is run, Prettier, ESLint, and Stylelint fix errors in the indexed files, and then the fixed files are re-added to the index.

• commit-msg:

  commitlint checks that the commit message complies with the Conventional Commits guidelines.

• Result:

  The commit is successfully completed if all checks pass, otherwise, the commit is rejected with an error message.