From 9d790708fb910d7e997c66b578f6990a5009405c Mon Sep 17 00:00:00 2001 From: SimGetti Date: Fri, 11 Aug 2023 15:51:46 +0200 Subject: [PATCH] Add conventions about branches and commit naming --- README.md | 44 ++++++++++++++++++++++++++++++++++++++------ 1 file changed, 38 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index c06b676..e4d584c 100644 --- a/README.md +++ b/README.md @@ -23,7 +23,9 @@ Encore merci, et bon code ! ### Conventions de nommage -Chaque branche doit être nommée sous la forme `[category]/[description]` +**Noms de branches** + +Chaque branche doit être nommée sous la forme `category[/#ticket-ref]/description` *category* détermine le type de modification que vous comptez effectuer au sein de la branche : - `feature` pour ajouter une fonctionnalité au projet$ - `fix` pour corriger un bug @@ -31,14 +33,17 @@ Chaque branche doit être nommée sous la forme `[category]/[description]` - `doc` pour effectuer des changements relatifs à la documentation (readme notamment) - `refactor` pour effectuer un changement au sein du code sans conséquence sur l'application - Vous pouvez ajouter une catégorie si le besoin s'en fait sentir, tout en s'assurant que le sens soit bien compréhensible de l'extérieur + Vous pouvez ajouter une catégorie si le besoin s'en fait sentir, tout en s'assurant que le sens soit bien compréhensible de l'extérieur. + + Entre la catégorie et la description peut s'insérer la référence du ticket Gitlab relatif à la branche. + + La description de la branche, en anglais et en kebab-case, doit décrire de manière très succinte l'objectif de la branche : dans quel but elle a été créée sans entrer dans le détail. - Les noms des branches, en anglais et en kebab-case, doivent décrire de manière très succinte l'objectif de la branche : dans quel but elle a été créée sans entrer dans le détail. Bons exemples : - - `feature/improve-pdf-generation` - - `fix/deadline-increments-on-duplicated-commands` + - `feature/#72/improve-pdf-generation` + - `fix/#117/deadline-increments-on-duplicated-commands` - `doc/explain-conventions` - - `refactor/is_ongoing-to-is_open` + - `refactor/#99/is_ongoing-to-is_open` Mauvais exemples : - `fix-some-stuff` @@ -46,6 +51,33 @@ Chaque branche doit être nommée sous la forme `[category]/[description]` - `feature/add-a-cool-ui-element-when-the-cursor-passes-over-the-calendar-where-the-user-can-also-choose-the-associated-hour` - `fix/edit-order/views/order.py-to-replace-is_ongoing-by-is_open` +**Noms de commits** + +Les noms de commits doivent être constitués de deux parties : un sujet et un corps (optionnel). +Le sujet fait office de titre du commit ; il se suffit souvent à lui-même et doit expliquer brièvement le but du commit. +Si besoin, le message de commit peut être enrichi d'un corps qui permet de détailler plus en détails ce qui a été modifié et pourquoi (mais pas comment !). + +Les noms des commits doivent respecter ces 7 règles d'or pour garantir une homogénéité dans le projet: +* Sépare le sujet du corps avec une ligne vide +* Limite la ligne de sujet à 50 caractères +* Met une majuscule à la lignde de sujet +* Ne finis pas la ligne de sujet avec un point +* Utilise le mode impératif dans la ligne de sujet (IMPORTANT) +* Limite la taille de ligne (*wrap*) du corps à 72 caractères +* Utilise le corps pour expliquer le quoi et le pourquoi (et pas le comment) + +Les détails de cette méthode sont détaillés dans ce tuto : https://cbea.ms/git-commit/ + +Bons exemples : + - `Refactor system X for readability` + - `Remove deprecated method` + - `Release version 1.4.2` + + Mauvais exemples : + - `Changing behaviour of X` + - `add submit button.` + - `Edit order.py line 72 to improve efficiency by adding recursive algorithm` + ## Versions - semantic versionning Les fonctionnalités développées dans les différentes versions sont listées dans le fichier [CHANGELOG.md](https://gitlab.com/hashbangfr/la_chariotte/-/blob/main/CHANGELOG.md).