Add conventions about branches and commit naming

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).