S’inscrire sur la forge git.spip.net
Pour proposer une modification sur git.spip.net il faut :
- lire la charte d’accueil de SPIP, puis, si vous souscrivez à celle-ci ;
- s’inscrire sur le forum de discussion ;
- demander un accès à la forge sur sa page d’inscription.
Règles de contribution
Dans les groupes Gitlab spip et spip-league
Cette section porte sur la contribution au noyau de SPIP et à ses plugins dist, et ne concerne pas la participation aux plugins communautaires.
- Créer un ticket sur https://git.spip.net/spip/spip/issues avant d’envoyer une proposition (qu’on nomme PR [1]).
- Créer une copie personnelle du dépôt (un fork) et y créer une branche qui contiendra les modifications proposées. Celle-ci doit-être nommée issue_xxx où xxx est le numéro du ticket associé.
- Les messages des commits de la branche issue_xxx doivent suivre la nomenclature des Commits Conventionnels. Le corps du message doit être clair et explicatif : décrire le problème traité et les évolutions ou corrections apportées. De plus, la série de commits doit être linéaire (sans commits de merge).
- Une fois la branche finalisée, faire une demande de fusion via l’interface de la forge en cliquant sur « nouvelle demande de fusion » depuis la branche en question. S’assurer que la PR ne contient pas de conflits. S’il y en a corriger à l’aide de
git rebaseetgit force push. La demande sera passée en revue et testée par les membres de l’équipe. Elle ne pourra être fusionnée qu’après avoir reçu au moins deux approbations de ses membres. - La branche issue_xxx peut être supprimée après fusion.
Une fois la branche fusionnée, l’équipe de maintenance se chargera d’ajouter une ligne dans le fichier CHANGELOG,
Les mêmes règles s’appliquent aux membres de l’équipe, pour qui il est recommandé de toujours passer une PR avant d’intégrer du code dans la branche master. Toutefois, si le patch est vraiment mineur et que la personne est certaine que cela ne casse rien, elle peut décider de l’envoyer directement dans la branche master à condition d’en assurer le suivi. Ces membres peuvent créer la branche directement dans le dépôt, sans fork.
Dans les groupes Gitlab spip-contrib-*
Cette section porte sur la contribution au plugins, squelettes et outils communautaires (Contrib), et ne concerne pas la contribution au noyau de SPIP et à ses plugins dist.
- Créer un ticket sur le plugin concerné avant d’envoyer une proposition (qu’on nomme PR [1]).
- Créer une branche qui contiendra les modifications proposées. Celle-ci doit-être nommée issue_xxx où xxx est le numéro du ticket associé.
- Certains plugins utilisent la nomenclature des Commits Conventionnels, ou bien ont des règles de contribution particulières (précisées dans un fichier texte "contributing" ou "readme"). Dans ce cas respecter ces règles et conventions.
- Une fois la branche finalisée, faire une demande de fusion via l’interface de la forge en cliquant sur « nouvelle demande de fusion » depuis la branche en question. S’assurer que la PR ne contient pas de conflits. S’il y en a corriger à l’aide de
git rebaseetgit force push. La demande sera passée en revue et testée par d’autres membres de la communauté. Elle ne pourra être fusionnée qu’après avoir reçu au moins deux approbations, ou bien directement par la personne qui a créé/qui maintient le plugin. - Si le plugin gère un fichier CHANGELOG, le mettre à jour.
- La branche issue_xxx peut être supprimée après fusion.
À propos des commits conventionnels et des fichiers Changelog
Lire les articles :
À propos de la fusion de branche
Dans la communauté SPIP (core et plugins) nous n’utilisons pas les commits de fusion de branche. Nous préférons, pour avoir un historique plus linéaire, utiliser un rebasage puis une avance rapide.
# Au sein de la branche à fusionner
git rebase master
# Bascule vers la branche principale
git switch master
git merge branche_a_fusionner
Il en est de même pour les pulls.
On optera donc pour la config git globale suivante :
git config --global pull.ff only
git config --global pull.rebase = true
git config --global merge.ff = true
Règle de cherry-pick
En général, lors d’un git cherry-pick, utiliser l’option -x.
Règles de présentation et d’écriture
Consulter les règles de codage.