Pourquoi utiliser les conventions ?
les conventions vont limiter les disparités dans la gestion des repositories et aussi communiquer la nature des changements aux développeurs ; au clients ; aux auditeurs.
il permet la mise en place d’automatismes et faciliter l’intégration de nouveaux développeurs dans nos projets en leur permettant un historique de commits structurés.
Cela marche car cela fait partie des leviers utilisés dans les communautés Open Source pour faire travailler ensemble des gens qui ne se connaissent pas.
Semantic Versionning:
Spécification largement utilisé dans les communautés Open Source pour standardiser la définition des numéros de version des packages applicatifs.
Format X.Y.Z (ex: 1.0.0 ; 1.13.2 ; 4.3.12).
Une nouvelle release va déclencher un incrément sur l’un des 3 chiffres:
- X = « major » : en cas de breaking change.
- Y = « minor » : en cas d’ajout de fonctionnalités
- Z = « patch » : en cas de bug fix
En cas d’incrément de Y ; Z est mis à 0
En cas d’incrément de X ; Y et Z sont mis à 0.
Conventional Commits:
Spécification visant à obtenir un historique de commit explicites à destination des consommateurs de nos repositories (clients ou membres de l’équipe)
Structure du message commit :
Les commits sont préfixés de manière obligatoire avec un type ; permettant de déterminer le type d’incrément SemVer
- fix: corrélation « patch »
- feat: corrélation « minor »
- {{ type }}!: (ou footer BREAKING CHANGE:) corrélation « major »
« Angular convention » étend la liste des types avec notamment refactor: , docs: , ci:
Quick FAQ:
Ca va nous freiner dans la vélocité à créer du contenu :
Cela décourage de le faire du rapide de façon désorganisée ; Cela aide sur le long terme lorsqu’on travaille sur de multiples projets avec des contributeurs variés.
Est-ce que 100% des contributeurs doivent utiliser les specs du « Conventionnal Commit » :
Pas forcément. Les « casual commiters » verront leurs commits réarangéspar les reviewers sur les Merge Requests. Un workflow spécifique peut être mis en place pour standardiser cela.
Que faire quand mon commit semble appartenir à plusieurs types :
Le déstructurer en plus petits commits ; cela va également faciliter la review de la PR.
J’ai utilisé le mauvais type de commit :
gitrebase -i (AVANT le merge sur branche principale)
Je dois corriger mon commit :
gitcommit –fixup SHA1 && git rebase -i –autosquash
Cas pratique:
Points forts:
Facilement exportable sur tous nos repositories
Language-agnostic
Workflow Gitlab + Workflow workstation
Points faibles:
Nécessite d’être rigoureux dans les commits
Based on:
pre-commit (lint (refuse les commits non conformes))
standard-version (changelog + tag repo)
Tooling : Pre-commits
Framework pour manager les git hook scripts, exécutés lors d’un commit.
Notamment utilisé en tant que linter pour valider le format du code
On trouve des dizaines de hooks ‘prêts à l’emploi’
1.“pip install pre-commit”
2.Ajout du fichier .pre-commit-config.yaml dans le repository
3.Installation des git hook scripts “pre-commit install”
Tooling : Standard-version
Utilitaire de versioning et de generation de CHANGELOG basé sur Conventional Commits
On l’éxécute une fois que le code de notre release a été review et mergé
Le contenu du changelog est défini en fonction des paramètres indiquésdans le fichier de configuration.
Ressources
https://www.conventionalcommits.org/en/v1.0.0/
https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format