Procédure de merge request

La merge request ou MR est un procéder sur Gitlab permettant de proposer une modification de code à un projet. Une branche représente une modification étant indépendante sur un périmètre de l'application.

Il faut savoir que la branche master (ou main sur les versions plus récente) est par défaut la source d'où seront tirés vos développements, c'est la branche mère ou votre version de travail. Une merge request est constitué d'une branche mère, représentant les modifications apportées au code, il est possible d'avoir plusieurs sous-branches la constituant.

Convention de nommage

Le nom d'une branche doit avoir un type ainsi qu'une courte description du sujet/contexte de la modification, en anglais de préférence.

Les différents type

• feat/ : rajout d’une nouvelle fonctionnalité
• fix/ : correction d’un bug
• poc/ : pour le développement de POC
• docs/ : Ajout ou modification de documentation
• opti/ : Amélioration des performances
• refactor/ : Modification n’ajoutant pas de fonctionnalités ni de correction de bug (renommage d’une variable, suppression de code redondant, simplification du code, etc.)
• test/ : Ajout ou modification de tests

Nom de branche valide:

• feat/nom_de_la_branche
• fix/nom_de_la_branche_2
• test/nom_de_la_branche

Nom de branche invalide:

• nom_de_la_branche
• test/nom_de_la_branche_vraiment_trop_longue_pour_etre_valable_en_realite

Création d'une branche

git checkout master # nous vérifions que nous sommes bien sur la branche master
git pull # nous mettons à jour la version locale

git checkout -b feat/randomize # nous créons une nouvelle branche en suivant la convention de nommage

git commit -am "feat/randomize: randomize generator" # création d'un commit gardant la convention de nommage
git push # mets à jour la branche sur le serveur distant

Création d'une merge request

Cette procédure est décrite pour la plateforme Gitlab, la procédure est sensiblement pareil pour Github.

Une fois que vous avez modifié la partie de code qui vous intéressait et que vous avez git push votre branche.

1. Retourner sur le repository Gitlab de votre projet.
2. Cliquer sur "Merge requests" dans la barre de navigation de gauche.
3. Cliquer sur le bouton bleu "New merge request".
4. Sur la gauche, sélectionner votre nouvelle branche puis à droite sélectionner la branche de destination. (branche master sauf si vous travaillez sur une autre branche mère)

Template description merge request

Lors de la création d'une MR, il est possible de rajouter une description qui nous sera utile lors de la revue de code. Cette description utilise du Markdown (guide Markdown Gitlab) qui est un langage à la syntaxe simple, permettant la mise en forme d'une page de texte.

# Contexte
Description du contexte de la merge request, contient les informations utiles à la compréhension des modifications apportées.

## Documents
- `C:\lien\vers\spec.docx`
- `C:\lien\vers\schema.pdf`

# MR liées
Cette partie est une liste exhaustive des autres MR pouvant être liées à la MR principale ainsi que leurs descriptions associées.
## [feat/randomize_back: Développement BACK](/lien/vers/merge_request/back)
Création des fonctionnalitées back-end pour la génération aléatoire de nom d'utilisateur.
- Création de l'entity Randomize
- Création de la requête dans RandomizeRepository
- Création de la route dans APIController: `@Route("/api/randomize", name="api_randomize")`
- Tests unitaires

## [feat/randomize_front: Développement FRONT](/lien/vers/merge_request/front)
Développement de la partie IHM avec l'utilisation de Bootstrap 5.2.

## [Draft: test/randomize: Optimization des tests unitaires](/lien/vers/merge_request/test)
Modification des tests unitaires et fonctionnels.

# Todo (facultatif)
- [x] tests unitaires
- [x] tests cucumber
- [ ] tests fonctionnels
- [ ] mettre à jour le statut du ticket

Merge request avec plusieurs branches

Si vous êtes plusieurs à travaillez sur une fonctionnalité, il est important que chaque branches soit indépendante afin de ne pas avoir de conflit lors de la merge request.

Lors d'un développement découpé en plusieurs sous-tâches, plusieurs sous-branches peuvent être développé puis fusionné dans une branche principale.

Il faut également penser à garder votre branche mère à jour et de récupérer les modifications sur les branches enfants.

git checkout master # mes collègues ont mis à jour la branche master
git pull # je récupère les modifications

git checkout feat/randomize # je re-bascule sur ma branche de travail
git merge master # je mets à jour ma branche de travail avec les modifications de la master

# Maintenant que je suis à jour, je peux mettre à jour les branches enfants sur lesquellles je travail encore.
git checkout test/randomize
git merge feat/randomize