Outils CI/CD
Collez vos commits, indiquez la version actuelle, et obtenez une proposition de version, un brouillon de changelog et un numéro de build.
Les commits et le numéro de version sont analysés dans votre navigateur. Rien n'est envoyé, et aucun service Git ou CI n'est jamais appelé.
Collez vos commits ou saisissez une version pour commencer.
Les lignes non reconnues ne bloquent jamais le calcul ; cette option décide seulement si elles apparaissent dans la section « Other » du brouillon de changelog.
Collez vos commits ou saisissez une version pour commencer.
Avant de poser un tag de release, on répond en général à trois questions à la main : quel est le prochain numéro de version, que doit contenir le changelog, et quel numéro de build accompagne cette release ? Cet outil, qui agit comme un calculateur de release sémantique, permet de générer un changelog depuis les commits à partir du même lot de commits, tout en produisant la proposition de version et le numéro de build en même temps, pour que les trois ne divergent jamais.
La différence avec une version incrémentée à la main ou des lignes copiées dans CHANGELOG.md : chaque suggestion provient de l'analyse de l'en-tête de chaque commit, avec la même grammaire que notre Conventional Commit Builder — pas d'un diff deviné ni d'un appel à une IA. Rien de ce que vous collez ne quitte le navigateur, et l'outil ne crée jamais de tag, ne pousse rien et n'appelle aucune API Git ou CI — il ne fait que produire du texte que vous utilisez ensuite vous-même.
Ce qui change quand la version, le changelog et le numéro de build proviennent des mêmes commits.
Certains calculateurs de release sémantique vous font décrire vos changements en texte libre et l'envoient à une IA qui devine un changement de version. Cet outil analyse plutôt chaque en-tête de commit avec la même grammaire que notre Conventional Commit Builder — la même entrée donne toujours la même proposition, sans jamais envoyer de requête réseau.
Un calculateur de version, un générateur de changelog et un générateur de numéro de build indépendants ne connaissent pas le résultat des autres. Ici, la version proposée alimente directement le titre du changelog et le marqueur {version} de votre modèle de numéro de build, si bien que les trois restent synchronisés. Le changelog produit fait aussi office de générateur de notes de version, prêt à être publié tel quel.
Une fois la release générée, le panneau de résultat renvoie directement vers notre outil ENV diff pour comparer les variables d'environnement avant le déploiement — une étape absente des générateurs de changelog et de numéro de build indépendants que nous avons comparés.
Ce qu'il faut savoir avant de coller votre premier lot de commits.
Collez les lignes telles que `git log --pretty=format:%s` les affiche — un `type(scope)!: subject` par ligne. Les messages multi-lignes avec un corps ou un footer `BREAKING CHANGE:` ne sont pas analysés ici ; indiquez plutôt un changement majeur avec `!` juste après le type ou le scope.
Saisissez la version actuelle au format SemVer strict (par ex. 1.4.2) et modifiez si besoin le modèle de numéro de build. Le modèle par défaut `{version}+{yyyyMMdd}.{count}` utilise la version proposée, la date du jour et un compteur de build que vous saisissez vous-même — l'outil n'a aucun contexte CI d'où lire un vrai numéro de build.
Désactivez la génération automatique pour modifier plusieurs champs avant de recalculer, puis appuyez sur Ctrl/Cmd+Entrée pour lancer une exécution manuelle.
Le badge (majeure, mineure, correctif ou aucun changement) indique quel commit a fait monter la version — un marqueur de changement majeur l'emporte toujours sur un simple feat ou fix. Confirmez la prochaine version, copiez ou téléchargez le changelog, copiez le numéro de build, ou suivez le lien ENV diff avant de poser le tag.
Toute modification des entrées grise le résultat précédent et désactive la copie et le téléchargement jusqu'à la prochaine génération.
Voir ce qui n'est pas analyséQuatre éléments qui transforment un lot d'en-têtes de commit en brouillon de release prêt à l'emploi.
Cet outil lit les lignes `type(scope)!: subject` avec la même grammaire que notre Conventional Commit Builder, classe l'impact de chaque ligne reconnue et retient le plus élevé — un seul `!` ou un seul `feat` dans le lot suffit à faire monter toute la release.
Les commits reconnus sont regroupés en Breaking Changes, Features, Fixes et Other, rendus en Markdown que vous pouvez copier, télécharger sous forme de CHANGELOG.md, ou utiliser comme générateur de notes de version — les entrées majeures sont toujours listées en premier.
Combinez `{version}`, `{yyyy}`, `{yyyyMM}`, `{yyyyMMdd}` et un `{count}` saisi manuellement pour obtenir le format de numéro de build attendu par votre pipeline ; les marqueurs inconnus restent tels quels et sont signalés au lieu d'être supprimés silencieusement.
Une ligne qui n'est pas un en-tête de commit valide est ignorée pour la proposition de version et comptée séparément, sans arrêter le calcul global — désactivez « ignorer » pour tout de même la voir dans la section Other du changelog.
Les cas limites à connaître avant de coller les commits d'une vraie release.
Les réponses à ce que les gens demandent vraiment avant de faire confiance à une proposition de version basée sur les commits.
Vérifiez que la ligne correspond exactement au format `type(scope)!: subject` — un deux-points manquant, un espace superflu ou une syntaxe non prise en charge rend toute la ligne non reconnue, et une ligne non reconnue ne contribue jamais à la proposition de version. Le nombre de lignes reconnues sous le résultat indique combien de lignes ont réellement été analysées.
Modifiez le modèle de numéro de build dans les options. Le modèle par défaut `{version}+{yyyyMMdd}.{count}` insère la version proposée par cet outil, la date du jour et un compteur que vous saisissez vous-même — il n'y a ici aucun environnement CI d'où lire un vrai numéro de build, donc `{count}` reste manuel.
Le numéro de version (comme 1.5.0) suit le versionnage sémantique et dépend de l'impact de vos commits. Le numéro de build est une chaîne distincte générée à partir d'un modèle — utile pour les systèmes CI qui doivent distinguer chaque build même quand le numéro de version ne change pas. Il peut inclure cette même version via `{version}`, ainsi qu'une date et un `{count}` saisi manuellement.
Collez simplement vos commits sous forme d'un en-tête par ligne : cet outil va générer un changelog depuis les commits, regroupés par feat, fix et changements majeurs, au format Keep a Changelog. Copiez-le ou téléchargez-le en CHANGELOG.md au lieu de le recopier à la main.
Une ligne qui ne correspond pas au format `type(scope)!: subject` est simplement comptée comme « non reconnue » et n'entre pas dans le calcul de la proposition de version. Par défaut, « ignorer les lignes non reconnues » est activé, donc elle n'apparaît pas non plus dans le brouillon de changelog — désactivez cette option si vous voulez la voir.
Vous n'avez pas trouvé votre réponse ?
Collez vos commits, confirmez la version actuelle, et obtenez en quelques secondes une proposition de version, un brouillon de changelog et un numéro de build.
Tout s'exécute localement dans votre navigateur — pas d'inscription, pas d'envoi, et aucun tag ni déploiement n'est jamais déclenché à votre place.
Toute l'analyse se fait localement dans votre navigateur, et rien n'est jamais taggé ni publié à votre place.