Git. Używaj typu w Commit Message i zbuduj idealny changelog

Wszystkie commit message repozytorium Angulara ma jakieś dziwne prefiksy. Dlaczego? O tym w dzisiejszym wpisie.

Prefiksy

Jeśli każdy Commit Message będzie posiadał jeden prefiks z listy dostępnych:

• feat: ... - nowa funkcjonalność
• fix: ... - poprawka błędu
• docs: ... - dokumentacja
• style: ... - formatowanie, brakujące średniki itp.
• refactor: ... - refaktoryzacja
• perf: ... - poprawa wydajności
• test: ... - dodanie brakujących testów
• build: ... - system budowania i zależności
• ci: ... - konfiguracja CI
• chore: ... - prace porządkowe
• revert: ... - wycofanie wcześniejszej rewizji

Opcjonalnie po typie można w nawiasie podać zakres (ang. scope), czyli część projektu, której dotyczy zmiana, np. feat(parser): ....

to wygenerowanie changeloga z podziałem na typ będzie przyjemnością.

Jakie kroki są potrzebne, aby używać takiego workflow:

1. Tworzyć Commit Message-e z prefiksem
2. Wygenerować CHANGELOG.md

Aby nie zapomnieć o typie podczas tworzenia rewizji wykorzystajmy dwa narzędzia:

• husky — podłączenie się pod zdarzenie tworzenia rewizji
• commitlint — weryfikacja treści Commit Message-a

Do wygenerowania changeloga przedstawię 4 narzędzia.

1. commitlint

• Instalacja

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

• Stworzyć plik commitlint.config.js o zawartości:

    module.exports = {
        extends: ['@commitlint/config-conventional']
    };
  

2. husky

• Instalacja

    npm install -D husky
    npx husky init
  

  Polecenie npx husky init tworzy katalog .husky/ i dopisuje do package.json skrypt prepare, który włącza hooki po npm install.

• Stworzyć hook .husky/commit-msg, który sprawdzi treść Commit Message-a:

    echo 'npx --no -- commitlint --edit "$1"' > .husky/commit-msg
  

Aktualizacja: 2026-09-26

W 2019 roku (husky do wersji 4) hooki konfigurowało się w package.json w polu "husky": { "hooks": { ... } }. Od wersji 5 husky ignoruje to pole, więc taki hook po cichu się nie uruchomi. Powyższa instrukcja dotyczy husky 9.

3. Changelog

Opcja nr 1 — git-changelog

• Instalacja

    npm install -D git-changelog
  

• Dodać zadanie w package.json:

    {
        "scripts": {
            "changelog": "git-changelog -e"
        }
    }
  

• Stworzyć plik .changelogrc. Format pliku dostępny w linku.

Uwaga: Brakuje wsparcia dla grupowania rewizji.

Opcja nr 2 — generate-changelog

• Instalacja

    npm i -D generate-changelog
  

• Dodać do pliku package.json rekomendowane zadania:

    {
        "scripts": {
            "release:major": "changelog -M && git add CHANGELOG.md && git commit -m 'Regenerate CHANGELOG.md' && npm version major && git push origin && git push origin --tags",
            "release:minor": "changelog -m && git add CHANGELOG.md && git commit -m 'Regenerate CHANGELOG.md' && npm version minor && git push origin && git push origin --tags",
            "release:patch": "changelog -p && git add CHANGELOG.md && git commit -m 'Regenerate CHANGELOG.md' && npm version patch && git push origin && git push origin --tags"
        }
    }
  

Uwaga: Brakuje wsparcia dla grupowania rewizji.

Opcja nr 3 — auto-changelog

• Instalacja

    npm install -D auto-changelog
  

• Dodać zadanie w package.json:

    {
        "scripts": {
            "changelog": "auto-changelog -u -l false"
        }
    }
  

Uwaga: Posiada wsparcie dla prefiksów.

Uwaga: Posiada wsparcie dla grupowania rewizji.

Przykład pracy auto-changeloga jest widoczny w bibliotece super-event-emitter.

Opcja nr 4 — REKOMENDOWANA — conventional-changelog

• Instalacja

    npm install -D conventional-changelog-cli
  

• Dodać zadanie w package.json:

    {
        "scripts": {
            "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
        }
    }
  

Uwaga: Posiada wsparcie dla ROŻNYCH typów prefiksów.

Uwaga: Posiada wsparcie dla grupowania rewizji.

Rozwiązanie problemu release bez changeloga

Jeśli zdefiniujemy zadanie version w run-scripts w package.json, to podczas uruchamiania npm version [major|minor|patch], zadanie zostanie wykonane przed stworzeniem nowej rewizji oraz taga. Jeśli dowolny plik będzie dodany do “Git Stage”, to npm version [major|minor|patch] doda ten plik do rewizji z podbiciem wersji.

Przykład rekomendowanego sposobu:

{
    "scripts": {
        "version": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0 && git add CHANGELOG.md"
    }
}

Więcej do poczytania na stronie projektu conventional-changelog

•

Narzędzia do zbudowania pliku CHANGELOG.md mogą być używane bez dodawania typów w Commit Message-u, tylko wtedy nie będzie pogrupowanych rewizji i wszystkie zostaną wrzucone do jednego worka.

Cya! 👋