Le projet se base sur le système de branches Git pour séparer les versions en cours de développement :
master: cette branche contient la version actuellement en productiondev: cette branche contient la version en cours de développement*: Toutes les autres branches contiennent des évolutions (pull-request)
Ce workflow est une version simplifiée du Git Workflow
Toutes les pull-requests sont automatiquement testés via Travis
- master
- dev
Pour ajouter une fonctionnalité, il faut créer une pull-request à merger sur la branche de dev.
Après la création et à chaque commit sur cette branche, les tests seront automatiquement executés par Travis
Les conditions pour que la pull-request soit mergée sont les suivantes:
- Les tests doivent être au vert
- Une revue de code doit être réalisée (si possible)
Une fois que la branche de dev regroupe un ensemble cohérent de fonctionnalités, il faut livrer cette branche dans le master.
Pour se faire, il faut créer une pull-request de la branche dev à merger sur la branche master.
Par convention nous appelons cette pull-request Mise en production (ex: #1039)
Pour information, le merge dans le master ne déclenche pas automatiquement un déploiement en production.
Pour corriger une anomalie en production, il faut créer une pull-request à merger sur la branche master.
Après la création et à chaque commit sur cette branche, les tests seront automatiquement executés par Travis
Les conditions pour que la pull-request soit mergée sont les suivantes:
- Les tests doivent être au vert
- Une revue de code doit être réalisée (si possible)
Une fois la branche hotfix mergée, il est nécessaire de rapatrier les modifications dans la branche de dev :
git checkout dev
git merge --no-ff origin/master
git push