changelogジェネレーター

まだ何もありません。上にいくつかの行を貼り付けて「生成」を押してください。

各行に対して何をするか

ルールは意図的にシンプルで見える化されており、推測するのではなく出力を予測できるようになっています：

1. Conventional commitはタイプごとにグループ化されます。`feat`は「新機能」、`fix`は「修正」、`perf`は「改善」になります。コロンの前の`!`、またはBREAKING CHANGEマーカーは、タイプに関係なくその行を「破壊的変更」に移動します。
2. conventional commitでないものは、最初の単語で並べ替えられます。Add、Added、Introduce、Supportは「新機能」に、Fix、Fixed、Resolveは「修正」に、Improve、Update、Speed、Optimiseは「改善」に、Remove、Removed、Drop、Deprecateは「削除」になります。それ以外は「その他」に入り、手動で並べ替えてください。
3. ノイズは取り除かれます：末尾のプルリクエスト番号、`Merge pull request ...`という行、括弧内のスコープ、そしてconventionalタイプのプレフィックス自体。残った文は大文字で始まります。
4. フィルターがオンの場合、`chore`、`ci`、`test`、`build`、`style`、`refactor`の行は、依存関係の更新に見えるものと一緒に除外されます。これが、人々が読むchangelogと読むのをやめるchangelogの唯一最大の違いです。

できないこと

あなたのコミットメッセージの形を書き換えますが、その内容は書き換えません。あるコミットが`fix: race in MembershipCache.resolve()`と言っている場合、出てくるのはそれであり、それでもユーザーの体験ではなくあなたのコードについての一文です。「MembershipCacheでのrace」を「招待されたメンバーが空のダッシュボードを見ることがなくなった」に変えるには、その変更が何をしたかを知る必要があり、それはジェネレーターがコミットの件名から推測できない部分です。

ですから、出力を最初の一歩として扱ってください：構造は正しく、グループ化は正しく、社内のノイズはすでになくなっていますが、言い回しはまだあなたが直す必要があります。

よくある質問

貼り付けたものはどこかにアップロードされますか？

いいえ。ジェネレーターはこのページ上のスクリプトであり、テキストがあなたのブラウザを離れることは一切なく、「生成」を押しても当社へのリクエストは発生しません。ネットワークタブを開いて確認できます。

conventional commitsを使う必要がありますか？

いいえ。慣習に従う行はより正確にグループ化され、それ以外は先頭の動詞にフォールバックします。通常の文形式のコミットメッセージを持つリポジトリでも、使える下書きが生成されます。

これを自分のリポジトリから自動的に取得するにはどうすればいいですか？

一度きりの用途には、`git log --pretty=format:%s v1.2.0..HEAD`がこれが期待する入力をそのまま提供します。継続的な用途には、git-cliffとgithub-changelog-generatorがどちらもコミット履歴からCI内でchangelogファイルを構築し、Changeloopはマージされたプルリクエストごとにユーザー向けのエントリを作成し、レビューのために保持します。

なぜ出力が「その他」だらけなのですか？

先頭の動詞が既知のものと一致しなかったためで、通常はコミットの件名が名詞やチケットIDで始まっていることを意味します。生成前にボックス内で編集するか、後で「その他」の行を手動で移動してください。

参考記事：conventional commitsからchangelogへ、コミット形式が何をもたらし、どこで止まるかについて。