Generator changeloga

Czytelna historia wydań zgodna z Keep a Changelog

Bezpieczne (SSL)

Przetwarzanie Lokalne

100% Darmowe

Przejdź do narzędzia

Instrukcja

1

Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku.
2

Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce.
3

Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.

                                                function runTool() {

                                                  return "Wynik gotowy w 0.1s";

                                                }

Wersja

Data

Dodano (jedna pozycja w linii)

Zmieniono

Przestarzałe

Naprawiono

Usunięto i bezpieczeństwo

Usunięto

Bezpieczeństwo

Sekcja [Unreleased]

Zmian: 4

# Changelog

Wszystkie istotne zmiany w projekcie są dokumentowane w tym pliku.
Format jest oparty na Keep a Changelog, a projekt stosuje wersjonowanie semantyczne.

## [Unreleased]

## [1.1.0] - 2026-09-13

### Dodano
- Nowa funkcja eksportu do CSV
- Obsługa trybu ciemnego

### Zmieniono
- Zwiększono wydajność listy wyników

### Naprawiono
- Poprawiono błąd walidacji formularza

Format Keep a Changelog grupuje zmiany według ich znaczenia. Wersjonowanie semantyczne MAJOR.MINOR.PATCH pomaga odbiorcom ocenić zakres wydania.

Oceń to narzędzie:

Powiązane narzędzia

Inne narzędzia, które mogą Ci się przydać

Generator CHANGELOG.md zgodny z Keep a Changelog

Generator changeloga zamienia krótkie notatki o wydaniu w uporządkowany plik Markdown. Podaj numer wersji, datę i zmiany, a narzędzie przygotuje sekcje zgodne z konwencją Keep a Changelog.

Dobry changelog nie jest kopią historii commitów. Ma wyjaśniać użytkownikom, administratorom i integratorom, co zmieni się po aktualizacji. Generator grupuje wpisy w kategorie Dodano, Zmieniono, Przestarzałe, Usunięto, Naprawiono oraz Bezpieczeństwo. Puste kategorie są pomijane, dzięki czemu wynik pozostaje krótki i gotowy do wklejenia do CHANGELOG.md.

Jak przygotować wpis wydania?

Wpisz numer zgodny z wersjonowaniem semantycznym, na przykład 1.4.0 albo 2.0.0-beta.1.
Wybierz datę publikacji w formacie RRRR-MM-DD.
Dodaj każdą zmianę w osobnej linii. Początkowy myślnik, gwiazdka lub plus zostanie ujednolicony.
Zostaw włączoną sekcję [Unreleased], jeżeli plik ma także zbierać pracę oczekującą na następne wydanie.
Skopiuj wynik i umieść najnowszą wersję nad starszymi wpisami w repozytorium.

Przyciski Patch i Major wczytują bezpieczne przykłady, ale nie zastępują decyzji o zakresie wydania. Jeśli proces publikacji działa w CI, wygenerowany fragment można połączyć z konfiguracją przygotowaną przez generator GitHub Actions albo z potokiem z generatora GitLab CI.

Sekcje i wersjonowanie semantyczne

Co oznaczają kategorie zmian?

Sekcja	Kiedy jej użyć	Przykład
Dodano	Nowa funkcja dostępna dla odbiorcy	Eksport raportu do CSV
Zmieniono	Zmiana istniejącego zachowania bez jego usunięcia	Szybsze filtrowanie wyników
Przestarzałe	Funkcja nadal działa, ale będzie wycofana	Zapowiedź usunięcia starego API
Usunięto	Element nie jest już dostępny	Usunięcie nieobsługiwanej opcji
Naprawiono	Poprawka błędu lub regresji	Naprawa walidacji formularza
Bezpieczeństwo	Usunięcie podatności lub wzmocnienie ochrony	Aktualizacja podatnej zależności

MAJOR, MINOR i PATCH

SemVer zapisuje wydanie jako MAJOR.MINOR.PATCH. Zwiększ MAJOR, gdy aktualizacja łamie zgodność publicznego API; MINOR, gdy dodaje funkcję zgodną wstecz; PATCH, gdy usuwa błąd bez zmiany kontraktu. Generator akceptuje także poprawne sufiksy prerelease i build, na przykład 2.0.0-rc.1 lub 1.4.2+build.7. Nie próbuje jednak sam oceniać wpływu zmian — ta decyzja należy do opiekuna projektu.

Numer i data są walidowane, a znaki sterujące nie mogą utworzyć dodatkowego nagłówka. Każda pozycja ma ograniczoną długość, a wynik jest prezentowany jako tekst, nie wykonywany HTML. Pozwala to bezpiecznie opisywać fragmenty kodu, nazwy gałęzi i identyfikatory zgłoszeń.

Jak pisać wpisy przydatne odbiorcy?

Opisuj efekt, a nie samą czynność programisty. „Dodano eksport faktur do CSV” mówi więcej niż „Merge PR #418”. Wspomnij o migracji, nowym wymaganiu lub zmianie konfiguracji, jeżeli użytkownik musi wykonać dodatkowy krok. Szczegółową historię implementacji pozostaw w commitach; ich spójny format pomaga utrzymać potok Jenkins i inne automatyzacje wydawnicze.

Uwaga: w sekcji Bezpieczeństwo nie publikuj instrukcji ułatwiających wykorzystanie niezałatanej podatności. Najpierw udostępnij poprawkę, a dopiero potem opisz wpływ i wersje objęte problemem.

Najczęściej zadawane pytania

Czym jest sekcja Unreleased?

To miejsce na zmiany połączone z główną gałęzią, które nie trafiły jeszcze do oznaczonego wydania. Podczas publikacji przenieś odpowiednie pozycje pod nagłówek z numerem i datą, a pustą sekcję pozostaw na kolejne prace.

Czy generator tworzy cały plik ze wszystkimi wersjami?

Narzędzie przygotowuje nagłówek oraz jeden wpis wydania. Skopiuj fragment nad starsze wersje w istniejącym pliku. Dzięki temu generator nie musi otrzymywać prywatnej historii repozytorium.

Czy numer wersji musi zaczynać się od litery v?

Nie. Akceptowane są zarówno 1.2.3, jak i v1.2.3. Najważniejsze, aby w całym projekcie stosować jeden sposób oznaczania tagów i wydań.

Czy można generować changelog bezpośrednio z commitów?

Tak, ale automatyczne narzędzie powinno opierać się na konsekwentnych komunikatach i nadal wymaga redakcji. Ręcznie przygotowany opis zwykle lepiej pokazuje wpływ na użytkownika niż lista technicznych commitów.

Gdzie umieścić CHANGELOG.md?

Najczęściej plik znajduje się w katalogu głównym repozytorium obok README i licencji. Link do niego można dodać w dokumentacji oraz w opisie każdego wydania, aby odbiorcy szybko znaleźli informacje o migracji.