@@ -21,15 +21,44 @@ Dans le formulaire il faut copier la clé publique uniquement dans le champ pré
## Cloner un dépot
## GitLabFlow
## Workflow Git
Avant de rentrer dans le fonctionnement du workflow et l'usage qu'on en fait petit rappel :
Une application Web Veremes a son propre dépot qui fait référence a des dépots Git de modules tous contenu dans le dossier src (à minima vitis et un autre module que ce soit gtf, vmap ou autre et potentiellement d'autre modules). Ce qui veut dire qu'une application Web Veremes c'est à minima trois dépots Git.
### Principe
Veremes utilise un gitflow assez classique en y incorporant des éléments du gitlabflow.
La documentation sur le flow d'origine est disponible à [ce lien](https://docs.gitlab.com/ee/topics/gitlab_flow.html).
Par convention Veremes, utilise la branche **master** pour livré les releases de ses applications, on peut considérer que c'est équivalent à une branche de production et la branche **next_version** pour les développements de nouvelles fonctionnalités.
Tous les projet sur Gitlab ont les labels **bug** et **évolutions**
Les versions qui sont représentés avec des tags au niveau du dépot git sont toujours sous cette forme Année.Release.Correctif (ex : 2023.01.01, premier correctif de la première release de l'année 2023).
Avant de sortir une version c'est à dire de réaliser les tags, il est préférable de créer une branche de pré-release (pre-20XX.XX.XX) pour tester la génération du setup, et la version elle-même.
### Contexte d'application
La branche **master** doit toujours être stable et préte à produire un correctif.
En cas de remonté de bug on crée une **issue** sur gitlab en lui ajoutant le label **bug**, le maintainer/responsable du projet, viendra assigner cette issue à un milestone en fonction de l'urgence de la demande, voir il y assignera un développeur.
Le développeur devra alors reporté l'issue sur le ou les bon(s) dépot(s), créer une branche et une merge request correspondantes sur chaque dépots concernés. Un bouton permet de le faire depuis l'issue, il faut laisser le nom par défaut et adapter la source, pour un bug ce sera master, pour un developpement next_version.
Le développeur va ensuite récupérer la branche sur son poste, corriger le problème et envoyer les modifications vers le serveur. Il devra alors passer la merge request en prète (en retirant le **Draft** au début) et l'assigner à un maintainer du dépot.
Le maintainer vérifiera alors que le correctif est fonctionnel et jugera de la qualité du code. En fonction de quoi, il renverrra des informations au développeur pour réaliser des modifications ou validera le code. En validant la merge request le maintainer réalisera le merge de la branche du correctif vers master et supprimera la branche du correctif (donc uniquement la référence vers le commit HEAD de cette branche, pas les commit en eux-même).
Il est également préférable de merger **master** dans **next_version** de façon à impacter le correctif sur la branche de développement également et s'éviter des risques de conflits ultérieurs.
En cas de développement de nouvelles fonctionnalités, c'est exactement la même chose, sauf que le label sur l'issue sera **évolutions** et que la branche source à utiliser au moment de la création de la merge request sera **next_version** (sauf exception cf. vitis pour vmap, ...).
Une fois le milestone terminé, que ce soit pour un correctif ou des évolutions, le maintainerdevra suivre le processus de sortie de version classique (détaillé ailleurs dans cette documentation).
