Jeszcze nic. Wklej kilka linii powyżej i naciśnij Generuj.Co robi z każdą linią
Zasady są celowo proste i widoczne, byś mógł przewidzieć wynik zamiast go zgadywać:
- Conventional commity są grupowane według typu. `feat` staje się Nowe, `fix` staje się Naprawione, `perf` staje się Ulepszone. `!` przed dwukropkiem lub znacznik BREAKING CHANGE przenosi linię do Zmian łamiących kompatybilność niezależnie od jej typu.
- Wszystko, co nie jest conventional commitem, jest sortowane według pierwszego słowa. Add, Added, Introduce i Support stają się Nowe; Fix, Fixed i Resolve stają się Naprawione; Improve, Update, Speed i Optimise stają się Ulepszone; Remove, Removed, Drop i Deprecate stają się Usunięte. Reszta ląduje w Inne, byś posortował ręcznie.
- Szum jest usuwany: końcowy numer pull requesta, linia `Merge pull request ...`, zakres w nawiasach i sam prefiks typu conventional commit. Pozostałe zdanie zaczyna się wielką literą.
- Przy włączonym filtrze linie `chore`, `ci`, `test`, `build`, `style` i `refactor` są odrzucane, wraz z wszystkim, co wygląda jak aktualizacja zależności. To pojedyncza największa różnica między changelogiem, który ludzie czytają, a takim, który przestają czytać.
Czego nie potrafi
Przepisuje kształt Twoich wiadomości commitów, nie ich treść. Jeśli commit mówi `fix: race in MembershipCache.resolve()`, to właśnie wychodzi, i wciąż jest to zdanie o Twoim kodzie, a nie o doświadczeniu użytkownika. Zmiana "race in MembershipCache" w "zaproszeni członkowie nie widzą już pustego panelu" wymaga wiedzy, co zrobiła zmiana, a to część, której generator nie może wywnioskować z linii tematu commita.
Więc traktuj wynik jako pierwsze podejście: poprawna struktura, poprawne grupowanie, wewnętrzny szum już zniknął, słowa wciąż musisz poprawić sam.
Częste pytania
Czy to, co wkleję, jest gdzieś przesyłane?
Nie. Generator to skrypt na tej stronie; tekst nigdy nie opuszcza Twojej przeglądarki i nie ma żadnego żądania do nas, gdy naciskasz Generuj. Możesz to potwierdzić z otwartą zakładką sieci.
Czy muszę używać conventional commits?
Nie. Linie zgodne z konwencją są grupowane dokładniej, a reszta wraca do początkowego czasownika. Repozytorium ze zwykłymi zdaniowymi wiadomościami commitów wciąż produkuje użyteczny szkic.
Jak uzyskać to automatycznie z mojego repozytorium?
Dla jednorazowego użytku `git log --pretty=format:%s v1.2.0..HEAD` daje dokładnie takie wejście, jakiego to oczekuje. Dla czegoś ciągłego, git-cliff i github-changelog-generator oba budują plik changeloga w CI z Twojej historii commitów, a Changeloop redaguje wpis skierowany do użytkownika na każdy zmergowany pull request i przetrzymuje go do recenzji.
Dlaczego mój wynik jest pełen Inne?
Początkowe czasowniki nie pasowały do niczego znanego, co zwykle oznacza tematy commitów zaczynające się od rzeczownika lub identyfikatora ticketu. Możesz je edytować w polu przed generowaniem, albo przenieść linie Inne ręcznie potem.
Dalsza lektura: od conventional commits do changeloga, o tym, co daje format commita i gdzie się kończy.
Wersja, która pisze też zdania
Changeloop czyta tytuł i opis każdego zmergowanego pull requesta, nie tylko linię tematu, i redaguje wpis o tym, co zmieniło się dla użytkownika. Sam filtruje aktualizacje zależności i refaktoryzacje, i przetrzymuje każdy szkic, byś go edytował przed publikacją. Darmowe dla jednego repozytorium, bez karty.
Zacznij za darmo