mirror of
https://framagit.org/la-chariotte/la-chariotte.git
synced 2025-05-01 11:22:24 +02:00
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
This commit is contained in:
Laetitia Getti
parent
9d790708fb
commit
3d9e1a1f6e
1 changed files with 63 additions and 57 deletions
120
README.md
120
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`
|
||||
|
|
|
|||
Loading…
Reference in a new issue