Wygeneruj CHANGELOG.md z git log
Plik CHANGELOG.md to historia projektu z punktu widzenia użytkownika: co dostał w wersji 1.2, co nowego w 1.3, co psuje wsteczną kompatybilność w 2.0. Format Keep a Changelog grupuje zmiany na "Features", "Bug Fixes", "BREAKING CHANGES" i innym. Wersjonowanie zgodne z SemVer.
To narzędzie czyta wyjście z `git log --oneline` (albo `git log --pretty=format:"%H %s"` dla pełnych hashy) i grupuje commity po typie Conventional Commits. Wynik: gotowa sekcja CHANGELOG.md z linkami do commitów, datą i numerem wersji.
Możesz wyłączyć typy, które nie powinny być widoczne dla użytkowników (docs, chore, ci...). Możesz też wkleić istniejący CHANGELOG.md, wtedy generator wstawi nową sekcję na górze, zachowując starsze wersje. Linki do GitHuba budowane są z URL-a repo, który wpisujesz.
Jak używać
- Wygeneruj listę commitów w terminalu: `git log --pretty=format:"%H %s" v1.2.0..HEAD` (commity od wersji v1.2.0 do dziś). Albo `git log --oneline v1.2.0..HEAD`, krótkie hashe, te same dane.
- Wklej output w pole "Wejście" po lewej. Generator parsuje każdą linię: hash + Conventional Commit (typ, scope, opis, breaking flag).
- Uzupełnij dane wersji: poprzednia (v1.2.0), bieżąca (v1.3.0), data release'u (domyślnie dziś), URL repo (do budowania linków `commit`).
- Wybierz typy commitów do uwzględnienia, chipy na dole panelu. Domyślnie włączone: feat, fix, perf, revert (te interesują użytkownika). Wyłączone: docs, style, refactor, test, build, ci, chore (wewnętrzne).
- Tryb "Dodaj do istniejącego CHANGELOG" (Switch), wklej obecny plik CHANGELOG.md, generator wstawi nową sekcję nad pierwszym `##` (czyli nad najnowszą wersją). Wynik to gotowy plik, wystarczy nadpisać.
- Skopiuj albo pobierz plik. Wklej do repo, commit "chore(release): v1.3.0", push, tag, publish.
Do czego się przydaje
Konkretne sytuacje, w których generator changelog skraca release:
- Release pakietu npm / PyPI / cargo. Przed publikacją chcesz mieć sekcję "What's new in 1.3.0" w README albo w opisie release na GitHubie. Wklejasz commity od ostatniego taga, dostajesz gotową sekcję.
- GitHub Release notes. Po wypchnięciu taga, GitHub pyta "Generate release notes". Wpisujesz w pole "describe this release" sekcję wygenerowaną tutaj, wygląda profesjonalnie, ma kliknięcia w commity.
- Dokumentacja klienta. Klient chce wiedzieć, co dodaliście w sprincie. Wyciągasz `git log v1.2.0..HEAD`, generujesz changelog, wysyłasz email albo wrzucasz do Confluence. Każdy commit z linkiem, czytelne grupy.
- Replacement dla `semantic-release` w projektach, gdzie automatyka jest przesadą. Dla małego projektu, gdzie release zdarza się raz na 2 miesiące, ręczne generowanie tu jest szybsze niż konfigurowanie pełnego pipeline z auto-release.
- Audit historyczny. Chcesz zobaczyć, co konkretnie zmieniło się między dwiema wersjami sprzed roku? Wklejasz output `git log v0.5.0..v0.7.0`, generujesz changelog, wynik jest pełnym podsumowaniem.
- Onboarding nowych członków zespołu. "Co się działo w projekcie przez ostatni rok?", wygenerowany changelog na 12 miesięcy daje pełny obraz.
Jeśli Twoje commity nie są jeszcze w formacie Conventional Commits, użyj naszego generatora commitów, żeby nowe commity miały dobry format. A jeśli chcesz wkleić changelog do README, generator README ma sekcję "Changelog" gotową do podpięcia linka.