Notes de version à partir de Git

Collez des messages de commit ou un diff unifié pour rédiger les notes. La suggestion de version repose sur les marqueurs des commits et doit être relue.

Fonctionne localement dans votre navigateur
Tout dans cet outil est traité dans ce navigateur. KivTools ne télécharge pas, ne stocke pas et n’appelle aucune API tierce avec votre entrée.
Commits ou diff GitCollez des Conventional Commits, des sujets de git log ou un diff unifié.
Projet de version Markdown
Exécutez l'outil pour voir la sortie locale ici.

Comment rédiger des notes de version depuis des commits ou un diff

Collez des sujets Conventional Commits — directement depuis git log --oneline si vous voulez — ou un diff unifié, et la page en fait un brouillon Markdown avec les changements groupés et un niveau major, minor ou patch suggéré.

Rien ici ne touche à un dépôt : le texte collé est analysé dans le navigateur, le bouton d'exemple remplit un échantillon, et Copier ou Télécharger sortent le brouillon sous forme de release-notes.md.

  1. Collez votre texte dans Commits ou diff Git : un sujet Conventional Commit par ligne, une liste git log --oneline ou la sortie d'un diff unifié avec des en-têtes diff --git.
  2. Cliquez sur Générer des notes de version. Les lignes qui ne sont ni sujets de commit ni contenu de diff — auteurs, dates, marqueurs de hunk — sont ignorées.
  3. Lisez le brouillon : les commits sont groupés sous Fonctionnalités, Corrections, Performance, Modifications, Documentation, Tests et Build et CI, et tout commit marqué ! ou suivi d'un pied BREAKING CHANGE est signalé.
  4. Vérifiez le niveau suggéré : major en cas de changement incompatible marqué, minor dès qu'un feat est présent, patch sinon. Le brouillon parle de suggestion car le numéro final vous revient.
  5. Copier ou Télécharger récupèrent le résultat ; le bouton Effacer vide les deux panneaux.

Ce que cette page lit et ce qu'elle vous laisse

Ce qui est reconnu

Les sujets de commit acceptent un préfixe de hash court ou long facultatif : abc1234 feat: … et un hash complet de 40 caractères sont donc lus comme des commits. La portée est conservée : feat(api): add filters arrive sous Fonctionnalités avec la portée entre parenthèses.

La liste des types est l'ensemble Conventional Commits — feat, fix, docs, style, refactor, perf, test, build, ci, chore — plus revert. Un diff exige de vrais en-têtes diff --git : la liste des fichiers et les comptes + / − ne proviennent que des lignes situées après un en-tête, un + isolé dans le texte n'est donc pas compté.

Le niveau de version est une suggestion

major = au moins un marqueur ! ou un pied BREAKING CHANGE ; minor = au moins un feat ; patch = tout le reste, y compris docs, tests, style et chore. Ces règles sont mécaniques : relisez le brouillon avant d'étiqueter une version.

La ligne de suggestion est du texte brut dans le brouillon et rien n'est publié nulle part : la sortie est tout ce que cette page produit.

Ce que cette page ne fait pas

Elle ne lit aucun dépôt Git, n'exécute pas git et n'appelle aucun service réseau : seul le texte collé est analysé.

Les formats en dehors de ces deux-là sont signalés plutôt que devinés : un champ vide répond par le rappel de collage, et un texte sans sujet de commit ni contenu de diff reçoit son propre message. Les résumés git diff --stat et les diffs binaires ne sont pas convertis en statistiques de lignes.

Outils récents :