GitLab
Merge Request (MR)
- La création d'une MR est obligatoire sur le projet. Chaque branche doit avoir sa MR
- Aucun approuve n'est obligatoire pour pouvoir merger la MR
Exemple :
Bonne pratique
Le développeur A prend son ticket, il crée la branche et termine son ticket. Il crée une MR, si tout va bien, il la merge, sinon, il corrige les problèmes puis merge.
Si besoin, d'autres développeurs peuvent venir s'informer sur le code du développeur A sans pour autant le bloquer dans son workflow
Mauvaises pratiques
- Ne pas créer de branche pour chaque ticket (coder directement sur la branche "develop")
- Ne pas passer par une MR
- Ne pas contrĂ´ler son code avant de passer la MR
Noms des Branches
Sauf cas exceptionnels (comme un hotfix) ou indications contraires, chaque ticket donne lieu Ă une nouvelle branche.
Aucune règle n'est définie sur le nommage de la branche mais il est quand même conseillé de suivre un certain patron.
Exemple :
Bonne pratique
Nom de branche valide : feat/DP1-495-nom-de-ma-branche
Le nom de la branche est composé de 3 parties :
- Commencer par décrire s'il s'agit d'une fixture (fix) ou d'une feature (feat)
- Mettre un /
- Ajouter le numéro du ticket que la branche traite (ici : DP1-495)
- Ecrire un nom de branche cohérent avec le changement effectué
Mauvaises pratiques
- Coder directement sur la branche develop
- Ne pas indiquer le numéro du ticket dans la branche
- Nommer sa branche avec un nom qui n'a aucun rapport "ma-super-branche"
- Ajouter des majuscules ou des caractères spéciaux dans le nom de la branche (/, ", ', etc.)