Générez CHANGELOG.md à partir du git log
Un CHANGELOG.md est l'historique du projet du point de vue de l'utilisateur : ce qu'il a obtenu en 1.2, ce qui est nouveau en 1.3, ce qui casse en 2.0. Le format Keep a Changelog groupe les changements en « Features », « Bug Fixes », « BREAKING CHANGES » et quelques autres. Va de pair avec SemVer.
Cet outil lit la sortie de `git log --oneline` (ou `git log --pretty=format:"%H %s"` pour les hashes complets) et groupe les commits par type Conventional Commit. Le résultat : une section CHANGELOG.md prête, avec liens de commit, date et numéro de version.
Vous pouvez masquer les types qui ne devraient pas être visibles pour les utilisateurs (docs, chore, ci, ...). Vous pouvez aussi coller un CHANGELOG.md existant : le générateur insère la nouvelle section en haut, en gardant les versions plus anciennes. Les liens GitHub sont construits à partir de l'URL du repo que vous fournissez.
Mode d'emploi
- Générez la liste des commits dans le terminal : `git log --pretty=format:"%H %s" v1.2.0..HEAD` (commits de la version v1.2.0 jusqu'à maintenant). Ou `git log --oneline v1.2.0..HEAD`, hashes courts, mêmes données.
- Collez la sortie dans le panneau « Input » à gauche. Le générateur parse chaque ligne : hash + Conventional Commit (type, scope, description, drapeau breaking).
- Renseignez les métadonnées de version : précédente (v1.2.0), actuelle (v1.3.0), date de release (aujourd'hui par défaut), URL du repo (sert à construire les liens `commit`).
- Choisissez les types de commits à inclure, les pastilles en bas du panneau. Activés par défaut : feat, fix, perf, revert (ceux qui intéressent les utilisateurs). Désactivés : docs, style, refactor, test, build, ci, chore (internes).
- Mode « Append to existing CHANGELOG » (Switch) : collez le CHANGELOG.md actuel, le générateur insère la nouvelle section au-dessus du premier `##` (c'est-à-dire au-dessus de la version la plus récente). La sortie est un fichier complet, écrasez l'ancien.
- Copiez ou téléchargez le fichier. Déposez-le dans votre repo, commit « chore(release): v1.3.0 », push, tag, publish.
Quand c'est utile
Situations concrètes où un générateur de changelog raccourcit la release :
- Une release npm / PyPI / cargo. Avant de publier, vous voulez une section « What's new in 1.3.0 » dans le README ou dans la description de la GitHub Release. Collez les commits depuis le dernier tag, obtenez une section prête.
- Notes de GitHub Release. Après avoir poussé un tag, GitHub demande « Generate release notes ». Collez la section générée ici dans « describe this release » : ça fait pro et les commits sont cliquables.
- Doc orientée client. Le client veut savoir ce qui a été livré dans le sprint. Tirez `git log v1.2.0..HEAD`, générez un changelog, envoyez-le par email ou collez-le dans Confluence. Chaque commit lié, groupes nets.
- Un remplaçant de `semantic-release` dans les projets où l'automation est excessive. Pour un petit projet qui sort une version tous les deux mois, générer manuellement ici est plus rapide que de configurer un pipeline d'auto-release complet.
- Un audit historique. Vous voulez voir exactement ce qui a changé entre deux versions vieilles d'un an ? Collez la sortie de `git log v0.5.0..v0.7.0`, générez le changelog, vous obtenez un résumé complet.
- Onboarding de nouveaux coéquipiers. « Que s'est-il passé dans le projet l'année dernière ? » : un changelog généré sur 12 mois donne la vue d'ensemble.
Si vos commits ne sont pas encore des Conventional Commits, utilisez notre constructeur de commit pour que les nouveaux commits atterrissent dans le bon format. Et si vous voulez lier le changelog depuis un README, le générateur de README a une section « Changelog » prête à l'emploi.