Renseignez par contre le nom de votre scénario/exercice (tel qu'il apparaît sur la plateforme) dans le champ *Project name*. C'est seulement le *Project slug* qui doit être standardisé, cela vous permet de changer de nom sans changer de dépôt. C'est à la fois plus simple pour que l'on recherche et que l'on accéde à vos dépôts.
Votre dépôt doit contenir au minimum ces deux branches :
-`master` : c'est votre branche stable, sur laquelle votre travail est considéré terminé, relu et définitif. Elle est synchronisée avec la plateforme sous l'année de promo seulement.
-`dev` : c'est votre branche principale de travail, vos modifications sont considérées stables (dans le sens où l'import sur la plateforme ne doit pas être cassé), mais votre travail pas nécessairement terminé ou pas parfaitement relu. Elle est également synchronisée sur la plateforme, mais sous l'année de promo + `-dev` (par exemple `/2042-dev/`).
Vous êtes libre d'utiliser toutes les branches dont vous avez besoin. Néanmoins, deux branches ont un rôle particulier pour le système de synchronisation.
Vous pouvez créer sur GitLab des dépôts pour vos différents projets liés à vos scénarios ou exercices. N'hésitez pas à créer des dépôts à côté des dépôts de vos exercices.
S'il s'agit d'un fichier ou d'un petit groupe de fichiers pour lequel créer un dépôt n'a pas d'intérêt, vous pouvez utiliser le dossier `resources` qui est présent dans chaque dossier d'exercice (ou d'étape de scénario).
Il est important de NE PAS déclarer de sous-module (*submodule*) vers des dépôts externes à gitlab et de ne pas utiliser le dossier `resources` pour faire un lien vers des dépôts que l'on peut retrouver à côté du dépôt de votre scénario/exercice. Cela alourdi inutilement le processus de synchronisation.
Il en résulte qu'en cas de modification d'une image, d'un PCAP ou similaire, l'historique du dépôt est pollué par des gros bouts d'octets sans intérêt.
Pour ne pas dégrader les performances de vos dépôts sur GitLab, vous DEVEZ utiliser LFS pour stocker vos fichiers binaires. De cette manière, ces fichiers, seront gérés par un processus de stockage différent (ils seront stockés sur S3 qui est capable de gérer une grosse quantité de gros fichiers, contrairement au volume RBD des dépôts Git).
Lorsqu'un ticket est ouvert et nécessite un travail ou une correction, vous devez lier la clôture du ticket au commit ou à la demande de fusion correspondant. Cela permet de mieux suivre les modifications et de faire les revues.
GitLab (comme GitHub et la majorité des forges à vrai dire) dispose d'un mécanisme permettant facilement d'indiquer dans le message de commit la relation avec un ticket ouvert : <https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically>.