Bonnes pratiques pour la création de Pull Request

Table des matières

Principes généraux

Les plugins majeurs de Lutèce bénéficient entre chaque version de dizaines de commits. Afin de maintenir la lisibilité de ces itérations, il est nécessaire qu’une Pull Request soit composée d’un seul commit correspondant à une évolution ou à une correction. Ainsi, il est par la suite possible d’identifier la source éventuelle de régressions et de réaliser un revert. De façon plus générale, tout ce qui participe à la lisibilité de la branche en cours de développement est à favoriser. Les commits intermédiaires, les commits mal ou non préfixés sont à proscrire.

La gestion de projets par tickets permettant de suivre les évolutions et corrections des plugins et modules Lutece est réalisée via Redmine.

Règles à respecter sur les PR

Les principes sont les suivants :

Une PR doit être intitulée clairement, le titre doit être préfixé LUT-[N° du ticket Redmine]
Le titre doit indiquer l’objectif du commit
Les commits sont ajoutés sur un fork du repo, sur une branche partant de la branche develop et avec un nom de la forme LUT-[N° du ticket Redmine]
Idéalement, un seul commit par PR, correspondant à la feature/correction
Éventuellement, une PR peut contenir plusieurs commits, s’ils correspondent à plusieurs features distinctes, mais dépendantes entre elles
La PR peut contenir aussi un commit de formatage : il faut isoler le formatage dans un commit dédié au formatage ou à la mise à jour des licenses, mais séparé du commit correspondant à l’évolution demandée.

PR en conflit

Si une PR est en conflit sur GitHub, il faut résoudre ces conflits et à nouveau soumettre la PR.

Pour résoudre les conflits, il faut par exemple :

créer une branche temporaire pour sauvegarder son commit
récupérer la dernière version de la branche develop officielle sur le fork en local
cherry-picker le nouveau commit sur develop
résoudre les conflits
mettre à jour la PR

ou alors :

faire un pull –rebase
etc…

Gestion des conflits entre PR

Si le développeur a connaissance de conflits potentiels entre PR existantes (par exemple, une PR doit être validée avant une autre), il faut l’indiquer dans un commentaire sur la page de la PR.

Fusion de commits

Exemple de commande Git pour fusionner l’historique des commits :

git rebase -p -i HEAD~4

Cette commande permet de remonter 4 commits en arrière, et de façon interactive propose d’agir sur les 4 commits, ce qui permet par exemple de squasher les trois derniers sur le premier.