From 3d9e1a1f6ee0275b633f0e1b227ede05a6b2f25c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Alexis=20M=C3=A9taireau?= Date: Fri, 18 Aug 2023 17:37:52 +0200 Subject: [PATCH] Minor changes on @Keirsos changes - removed `#` in branch names - used `-` for lists, and added a space with a the previous line - moved the naming section at the end of the README --- README.md | 120 ++++++++++++++++++++++++++++-------------------------- 1 file changed, 63 insertions(+), 57 deletions(-) diff --git a/README.md b/README.md index e4d584c..b32fc35 100644 --- a/README.md +++ b/README.md @@ -21,63 +21,6 @@ Ensuite, un mainteneur de la Chariotte pourra relire votre code et proposer des Encore merci, et bon code ! -### Conventions de nommage - -**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 - - `test` pour effectuer des changements n'étant associé à aucun besoin déjà spécifié - - `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. - - 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. - - Bons exemples : - - `feature/#72/improve-pdf-generation` - - `fix/#117/deadline-increments-on-duplicated-commands` - - `doc/explain-conventions` - - `refactor/#99/is_ongoing-to-is_open` - - Mauvais exemples : - - `fix-some-stuff` - - `readme` - - `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). @@ -294,3 +237,66 @@ classDiagram email } ``` + +## Conventions de nommage + +### Nommage des 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 + - `test` pour effectuer des changements n'étant associé à aucun besoin déjà spécifié + - `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. + +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. + + Bons exemples : + + - `feature/72/improve-pdf-generation` + - `fix/117/deadline-increments-on-duplicated-commands` + - `doc/explain-conventions` + - `refactor/99/is_ongoing-to-is_open` + + Mauvais exemples : + + - `fix-some-stuff` + - `readme` + - `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 des 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 ligne de 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`