Git - MR/PR

Thomas S.

2024-2024

Sommaire

• Explications

MR/PR ?

• MR: Merge request
• PR: Pull request

Quel intérêts ?

• Avoir un code compréhensible
• Voir des potentielles failles
• Augmenter la force de l'équipe

Principe

Un projet à une branche principale: main ou master.
Parfois une branche intermédiaire (dev qui devient celle par défaut)
On souhaite ajouter une fonctionnalité, on créé alors une issue et une branche.
On travaille dessus. On pousse le travail.
Le collègue relit. On corrige si besoin.
On merge.

Nommage de la branche

Pas de règle, ça dépend de la politique de la société.
pseudo/type/titre
pseudo/id_issue/titre
pseudo/id_issue
id_issue/titre

Les / sont interprétés par les outils dans l'interface (en général).

Créer la MR/PR

• Bien choisir la branche de destination (dev ou master)
• Mettre un titre explicite
• Mettre des reviewers compétents
• Informer les reviewers

Avancement de la MR/PR

1. Le reviewer fait des remarques si besoin
2. Le reviewer valide la lecture de chaque fichier (checkbox)
3. L'auteur corrige en fonction des remarques et repush
4. Revenir à l'étape 1 si besoin
5. Valider le merge du code dans la branche de destination
6. Si besoin créer un tag

MR/PR & CI

• Pas de règles précises
• Basique: Tests simples et lint
• Avancé: Tests complets, lint, build, déploiement