Branches

• main, branche qui contient le code du site tel qu'il est en intégration
• les releases pointent sur la branche main (historiquement sur la branche production)

Cycle de développement

1. Pour chaque ensemble de modifications, créer une branche associée(sur le repo principal ou sur un fork perso, au choix).
2. Une fois les modifications faites, créer une Pull request sur GitHub.
3. Si un·e relectrice·eur ne s'est pas manifesté·e au bout de 48 h, relancer en mettant un message dans la PR.
4. Quand la Pull request a été relue et validée :
   1. rebaser la branche par rapport à main (manuellement, ou en mettant un commentaire "/rebase" dans la PR),
   2. merger la PR.

Bonnes pratiques pour les commits

• Donner un nom descriptif à ses branches
• Dans le cas où un commit corrige un bug ou implémente une feature, mentionner dans le message de commit le numéro de l'issue avec Fix #XXXX ou Ref #XXXX
• Les messages de commit sont écrits en anglais
• Faire une branche par "sujet", ne pas faire de branches trop lourdes
• Faire les commits les plus unitaires possible

Bonnes pratiques pour les PR

• Toujours mettre un message décrivant l'objet de la PR
• Si la PR concerne des changements visuels, mettre une capture d'écran
• Les commits correctifs sont à fixuper dans les commits qu'ils corrigent
• Séparer les modifications relatives à du nettoyage dans un commit séparé, voire une PR séparée

Attention

• Ne pas utiliser le bouton "Update branch" de GitHub. Ce bouton merge main dans la feature branch – ce qui casse l'historique semi-linéraire. (Nous, ce qu'on voudrait, c'est rebaser). À la place, rebaser manuellement la feature-branch sur main (ou mettre un commentaire "/rebase" dans la PR).