Générateur de modèles CHANGELOG.md
Générez des modèles CHANGELOG.md conformes à Keep-a-Changelog avec des groupes de versions sémantiques, des journaux inédits et des références de comparaison automatisées de balises Git.
Fill in your project name, repository link, and release version logs to export a Keep-a-Changelog standard markdown document.
Display name of your application.
A brief, one-sentence tagline.
Required to generate Git tag comparison links.
Determines formatting structure and links.
Release Version History & Logs
Pourquoi utiliser notre générateur de modèles CHANGELOG.md ?
- Norme Keep-a-Changelog : garantir le strict respect des spécifications. Notre outil génère des journaux de modifications standard v1.1.0 contenant des catégories sémantiques standard correctement ordonnées.
- Liens de comparaison automatisés : augmentez la crédibilité du référentiel. Fournissez l'URL de votre référentiel GitHub pour compiler automatiquement les URL de référence de comparaison entre toutes les balises en bas.
- Formats de sortie multiples : obtenez le format qui convient à votre flux de travail. Exportez sous forme de démarque Keep-a-Changelog, de puces Common Changelog ou de clean Notes de version GitHub.
- Confidentialité 100 % côté client : protégez les détails de votre projet. Le générateur gère tous les paramètres de formulaire, les journaux de publication et le rendu des modèles localement dans votre navigateur Web.
Qu'est-ce que la norme Keep-a-Changelog ?
Keep a Changelog est une spécification communautaire largement adoptée qui établit une structure uniforme et lisible par l'homme pour les journaux de modifications de projet. Au lieu de regrouper toutes les mises à jour dans une seule liste à puces massive, la norme définit strictement six groupes sémantiques : **Ajouté, Modifié, Obsolète, Supprimé, Corrigé et Sécurité**. Ce regroupement par catégories permet aux développeurs, aux gestionnaires et aux utilisateurs finaux d'analyser incroyablement facilement vos notes de version et de localiser rapidement les ajouts de fonctionnalités critiques, les alertes de dépréciation ou les mises à jour de sécurité.
Pourquoi les journaux de validation Git ne remplacent pas les journaux de modifications
De nombreux développeurs transfèrent par erreur leurs journaux Git bruts directement dans un fichier texte et l'appellent un journal des modifications. Cependant, les journaux git sont conçus pour les **machines et les compilateurs**, remplis de micro-commits, de corrections de fautes de frappe, de journaux de branche de fusion et de notes centrées sur le code. Un journal des modifications professionnel est conçu pour les **personnes**. Il organise ces validations, filtre les mises à jour sans conséquence et traduit les modifications brutes en descriptions claires destinées à l'utilisateur. Les journaux manuscrits garantissent que les développeurs peuvent lire et comprendre les nouveautés et leur impact sur leur intégration.
Les principes fondamentaux du versioning sémantique (SemVer)
L'adhésion au versioning sémantique représente le fondement d'écosystèmes logiciels stables. Un numéro de version SemVer est structuré comme Major.Minor.Patch (par exemple 1.2.3). La version **PATCH** est incrémentée lorsque vous publiez des correctifs de bogues rétrocompatibles. La version **MINEUR** est incrémentée lorsque vous ajoutez de nouvelles fonctionnalités rétrocompatibles. La version **MAJOR** est réservée aux modifications d'API qui nécessitent que les utilisateurs mettent à jour leurs intégrations. Le suivi de ces versions dans un journal des modifications structuré garantit la sécurité et la transparence de vos dépendances.
La puissance des liens de comparaison Git automatisés
Un journal des modifications véritablement professionnel ne se contente pas de répertorier les versions, il les connecte. En incluant des références de liens de comparaison au bas de votre fichier, les utilisateurs peuvent cliquer sur n'importe quel numéro de version pour afficher la différence de code exacte sur GitHub entre la version actuelle et la balise précédente. Ce générateur compile automatiquement ces liens de référence de comparaison en fonction de l'URL de votre référentiel. Il mappe les versions ultérieures aux répertoires de comparaison GitHub et balise correctement la version initiale, renforçant ainsi la confiance et la transparence des développeurs.
Foire aux questions
Le générateur de modèles CHANGELOG.md est un outil en ligne gratuit qui crée automatiquement des fichiers CHANGELOG.md prêts pour la production et conformes à Keep-a-Changelog. Il prend en charge les éléments de version personnalisés, les sections inédites et les liens de comparaison Git automatisés.
La spécification définit exactement six catégories pour regrouper toutes les modifications de code : ajoutées (nouvelles fonctionnalités), modifiées (modifications des fonctionnalités existantes), obsolètes (fonctionnalités qui seront bientôt supprimées), supprimées (fonctionnalités supprimées), corrigées (corrections de bogues) et sécurité (correctifs et améliorations de sécurité).
En fournissant l'URL de votre référentiel GitHub, le générateur compile automatiquement les références de comparaison Markdown au bas du fichier. En cliquant sur l’en-tête d’une version, les utilisateurs accèdent directement à la vue de comparaison des différences de GitHub montrant les modifications entre la balise de version actuelle et la balise précédente.
Les journaux de validation Git sont techniques, détaillés et destinés aux machines. Un journal des modifications écrit à la main est spécialement conçu pour les lecteurs humains. Il filtre les commits triviaux, regroupe les modifications dans des catégories sémantiques claires et explique le bénéfice ou l'impact réel des modifications.
L'outil fournit un format de démarque spécifique aux versions GitHub qui supprime les métadonnées d'en-tête et les liens de référence. Cela fournit des listes à puces propres et copiables, regroupées par emojis, pouvant être collées directement dans les tableaux de bord des versions GitHub/GitLab.
Oui! Vous pouvez spécifier n'importe quelle balise de version sémantique standard, y compris les balises de pré-version telles que 1.0.0-beta.1 ou 1.0.0-rc.2. Le système de validation le traitera correctement selon la spécification SemVer 2.0.0.
Oui, 100%. Tous les traitements et compilations de modèles s'effectuent localement dans votre navigateur Web à l'aide de JavaScript côté client. Aucune variable d'environnement, paramètres de port, clés secrètes ou extraits de code ne sont jamais transmis ou téléchargés sur un serveur, garantissant une confidentialité totale.