Appearance

Commits ​

Pour le moment, tu peux nommer tes commits comme tu l'entends. Mais plus on avance, plus on va tacher de durcir la politique de ces messages. ça nous aidera surtout à mieux gérer le versioning de nos projets. Rien de bien compliqué:

  1. Tes messages doivent tous avoir un prefixe feat: ou fix:
  2. Le titre du commit doit être entre 30 et 200 charactères
  3. On annote les breaking change avec feat!:

On peut aussi ajouter un scope à ce qu'on fait:

  • feat(api): added a version endpoint to see currently deployed version
  • fix(frontend): error when displaying empty task

Et on a d'autre préfix qu'on peut utilsier au besoin :

build:, chore:, ci:, docs:, style:, refactor:, perf:, test:

Pourquoi se faire autant chier ? ​

Changelogs ​

La meilleure raison de bosser avec des commits comme ça, c'est qu'à partir d'une liste de commits comme ça :

 - chore(release): 1.0.1
 - Merge branch 'release/1.0.1-staging.2' into 'develop' 
 - chore(release): 1.0.1-staging.2
 - docs: rewrote README for a more complete onboarding Calixte Mayoraz
 - chore: pointing all npm registry to new npm internal server 
 - fix: profile highlighted when in my-travels page
 - chore: change faq icon and renamed vue to "Others" for consistency 
 - Merge branch 'release/1.0.1-staging.1' into 'develop' 
 - chore(release): 1.0.1-staging.1 
 - Merge branch 'release/1.0.1-staging.1' into 'main' 
 - chore(release): 1.0.1-staging.1 
 - Merge branch 'release/1.0.1-staging.0' into develop 
 - fix: pin release-it t o v19 for plugin compatibility 
 - Merge branch 'release/1.0.1-staging.0' into 'develop'
 - chore(release): 1.0.1-staging.0 
 - fix: release-it ignores branch
 - fix: release-it needs develop branch. 
 - fix: ignoring untracked files in release script

On peut génerer automatiquement un Changelog :

CHANGELOG.md

Versioning ​

Si on veut suivre un workflow avec du versioning propre, il faut aussi suivre une certain rigueur. Imaginons qu'on a une certaine version d'un repository qui est déployé : 1.2.3.

Le client trouve un bug, on le patch et on commit un fix: pour réparer ce bug. On une incrémentation automatique peut se faire vers 1.2.4.

On continue d'avancer pour le sprint, on ajoute des features. Pour chaque commit feat: on peut incrémenter : 1.3.0.

On continue de bosser au fil des mois. Une nouvelle GROSSE fonctionnalité se fait (breaking change.) et le commit avec cela est push : feat!: .... et la version majeure se fait incrémenter: 2.0.0

Quand on fait une release avec plein de commits, des outils come semantic-release peuvent ensuite choper TOUTE cette liste de commits, et déterminer la prochaine version.

Contributors

The avatar of contributor named as Clément Favre Clément Favre

Changelog