Conventions Git
Voici la page présentant les conventions Git adoptées par l'équipe pour assurer le bon fonctionnement de tous.
L'équipe a décidé d'opter pour le Trunk-Based Development comme façon de fonctionner avec Git. Ainsi, l'équipe fonctionne avec une branche principale main qui est la version fonctionnelle de l'application et la source d'origine. Lorsqu'une personne désire créer une nouvelle fonctionnalité, celle-ci doit partir de la dernière version de la branche principale main et créer une nouvelle branche et une Pull-Request associée pour sa fonctionnalité. Une fois la fonctionnalité testée, approuvée et complétée, la Pull-Request est squash and merge dans la branche principale main. Les branches fermées doivent être supprimées afin de garder le repo le plus propre possible.
Pour ce qui est de la mise en production (MEP), il suffit de tagger le commit sur la branche main que l'on désire envoyé en production. Les tags devraient être nommés de la façon suivante: MEP#X Y, où X est le numéro de la MEP et Y est le nombre du tag de la même MEP (Ex: MEP#1 2 pour le 2e tag de la MEP#1).
L'équipe foncitonne sous le Conventional Commit. Cette convention spécifie la forme que doivent avoir le nom des commits et des branches. En voici un résumé:
La structure d’un commit se présente comme suit :
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Liste des principaux types utilisés:
| Commit Type | Title | Description |
|---|---|---|
feat |
Features | A new feature |
fix |
Bug Fixes | A bug Fix |
docs |
Documentation | Documentation only changes |
style |
Styles | Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) |
refactor |
Code Refactoring | A code change that neither fixes a bug nor adds a feature |
perf |
Performance Improvements | A code change that improves performance |
test |
Tests | Adding missing tests or correcting existing tests |
build |
Builds | Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) |
ci |
Continuous Integrations | Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) |
chore |
Chores | Other changes that don't modify src or test files |
revert |
Reverts | Reverts a previous commit |
source: Vanduynslager,P. (2017). conventional-commit-types. https://github.com/pvdlg/conventional-commit-types#commit-types
Les commits sont courts (50 à 70 caractères) et représentatifs.
Voici un exemple de nom de branche pour une foncitionnalité de prise de photo:
Nom de commit: feat: add camera dependencies
Nom de branche: feat/capture-photos
Voici les critères à respecter pour les Pull-Request:
- Une Pull-Request doit être ouverte le plus rapidement possible lorsqu'une issue est débutée
- Lorsque la Pull-Request n'est pas prête, sont titre doit débuter par
Draft: - Pour considérer une Pull-Request comme prête, celle-ci doit être testée, répondre à tous les critères d'acceptation et doit fonctionner complètement, car elle s'en va "directement en production"
- Une fois la Pull-Request prête,
Draft:doit être retiré du titre pour le signaler au reste de l'équipe - La Pull-Request doit être review et approuvée par au moins 2 autres coéquipiers
