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

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(feature): ...
fix(bug fix): ...
docs(documentation): ...
style(formatting, missing semicolons): ...
refactor: ...
test(when adding missing tests): ...
chore(maintain): ...

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

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

Tworzyć Commit Message-e z prefiksem
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ę 3 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
```

Dodać do pliku package.json następujący wpis (w głównym obiekcie):

  {
      "husky": {
          "hooks": {
              "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
          }
      }
  }

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.