Gitflow & Environnements
Gitflow est un modèle de branching Git alternatif qui utilise des branches de fonctionnalité et plusieurs branches primaires. Il a été publié et popularisé pour la première fois par Vincent Driessen de chez nvie. Comparé au développement basé sur le tronc, Gitflow dispose de davantage de branches plus longues et de commits plus importants. Dans ce modèle, les développeurs créent une branche de fonctionnalité et attendent que la fonctionnalité soit terminée pour la merger à la branche « trunk » principale (master ou develop par exemple). Ces branches de fonctionnalités au long cours nécessitent une plus grande collaboration lors du merge, car elles risquent davantage de dévier de la branche « trunk ». Elles peuvent également introduire des mises à jour conflictuelles.
Gitflow est parfaitement adapté aux projets avec un cycle de livraison planifié et pour les bonnes pratiques DevOps de livraison continue. Il n'ajoute aucun nouveau concept ni aucune nouvelle commande en dehors de ce qui est exigé pour le workflow de branche de fonctionnalité. Il assigne plutôt des rôles très spécifiques aux différentes branches et définit comment et quand elles doivent interagir. Outre les branches de fonctionnalité (feature), le workflow utilise des branches individuelles pour la préparation, la maintenance et l'enregistrement des livraisons. Bien évidemment, vous bénéficiez également de tous les avantages du workflow de branche de fonctionnalité : pull requests, expériences isolées et collaboration plus efficace.
La branche master sert l'environnement de production.
Un push sur cette branche met à jour automatiquement l'environnement de production, déployé pour le moment sur Heroku. On ne doit jamais travailler directement sur la branche master (hors cas Hotfix). Cette branche est mise à jour par la branche develop suite à une Pull Request.
La branche de développement, ou develop sert l'environnement de développement.
Un push sur cette branche met à jour automatiquement l'environnement de développement. On ne doit (normalement) jamais travailler directement sur la branche develop. Cette branche est mise à jour par les branches front, back ou IA, qui elles-même héritent de branches feature ou bugfix.
Fiches&Chips règne pour le moment sous 2 environnements principaux :
Cet environnement est utilisé pour faire tourner Fiches&Chips en production.
Cet environnement est utilisé par les développeurs pour tester les fonctionnalités en cours de développement qui seront intégrées à la prochaine version de Fiches&Chips
L'utilisation de différents environnements permet de séparer complètement le produit proposé à ses utilisateurs du produit développé par ses développeurs. Par exemple, il est pertinent de séparer les bases de donnée de production et de développement. Cela permet de travailler sur de nombreuses features, sans pour autant impacter le fonctionnement de l'application en production.
L'environnement de developpement (branche develop) hérite elle de 3 sous-branches principales :
C'est sur cette branche que toutes les tâches côté Front-End seront merge.
C'est sur cette branche que toutes les tâches côté Back-End seront merge.
C'est sur cette branche que toutes les tâches côté Front-End seront merge.
Ces sous-branches seront ensuite régulièrement merge sur develop, qui elle sera merge sur master (en production) lorsque toutes les tâches seront testées et validées. Ces tests doivent être produits en fin de sprint/milestone, lorsque tout le travail est validé et merge sur develop. En développant une rigueur sur le gitflow, sera permettra à l'équipe d'avoir plus de contrôle sur ce qui est en developpement et en production.
Lors du merge sur develop, chaque responsable de pôle doit rebase chaque commit.
Cela permet d'éviter d'envoyer un trop grand nombre de commits sur la branche develop
La manipulation des commits se fait via la commande
git rebase -i develop
Une feature se base dans l'idéal sur une branche release, ou sur une milestone. Dans l'idée, une Milestone regroupe un ensemble de tâches venant à apporter une nouvelle feature au projet.
Exemple : développer le chat textuel durant une campagne. Cette feature sous-entend plusieurs tâches, comme par exemple envoyer un message à un utilisateur, tout le monde, pouvoir interpréter des commandes etc...
git checkout milestone/FC-<Numéro|NomDeLaMilestone> ou git checkout releaseX.XX pour se déplacer vers la remote branch adéquate,
git pull pour mettre à jour la branche en local,
git checkout -b feature/FC-<numéro de la tâche sur **Github**> pour créer une branche depuis la branche où l'on se situait précédemment.
Les commits doivent suivre la nomenclature suivante :
[Type De Tâche][FC-<numéro de la tâche sur Github>] Message de commit
Exemples:
- [Feature][FC-38] Rajout des routes /about et /login
- [Bugfix][FC-64] Bugfix de la méthode GET du endpoint /api/users
Pour commit, rien de plus simple :
git commit -am "[Feature][FC-<numéro de la feature sur **Github**>] Your first commit"git commit -am "[Feature][FC-<numéro de la feature sur **Github**>] Your second commit"
Le flag -am est une fusion entre les deux flags, -a et -m :
- Le flag
-aajoute toutes les modifications faites en local, - Le flag
-mpermet d'ajouter un message à son commit.
Pour ceux qui utilisent Oh-my-zsh, des alias très pratiques sont disponibles (comme par exemple
gcmsgqui est un alias degit commit -m). Vous avez tous les alias disponibles ici.