TP 3 - GitLab

Ce TP a pour objectif d’utiliser le gestionnaire de version git et la forge de Nantes Université basée sur le logiciel GitLab.

1. Premiers pas avec GitLab et git

GitLab est un formidable outil pour gérer n’importe quelle sorte de projet, et que nous vous recommandons d’utiliser tout au long de votre cursus à Nantes Université, pour tous vos enseignements et pas seulement dans ce module de développement logiciel. C’est un outil particulièrement pratique pour éviter les pertes de données, et pour travailler à plusieurs sur un même projet.

Dans cette première partie, nous allons découvrir la forge logicielle GitLab installée à Nantes Université, et nous allons faire nos premières commandes git pour versionner des fichiers.

1.1. Création d’un projet GitLab

Voyons d’abord comment créer votre premier projet GitLab.

Connexion : rendez vous sur https://gitlab.univ-nantes.fr, et connectez vous avec vos identifiants habituels pour Nantes Université. Vous êtes ainsi connecté sur la forge, ce qui vous permet de vous promener au sein de tous les projets publics existants. Notez que les projets privés ne sont pas pas visibles au sein de cette liste.

Attention à ne pas utiliser le site https://gitlab.com/, qui est lui le site officiel du logiciel de forge GitLab (dont une instance est installée à l’université), et qui permet lui aussi la création de projets !

Création d’un projet : tout en haut, cliquez sur l’icône en forme de ➕, et choisissez « Nouveau Projet ».
Parmi les choix possibles, choisissez « Créer un projet vide ». Avant de valider, vous devez alors saisir :
- Le nom du projet, si besoin en plusieurs mots avec des espaces − mettez ce que vous voulez.
- Le Niveau de visibilité, qui permet de choisir parmi :
  - Privé : le projet n’est visible que de vous et des collaborateurs ajoutés au projet − choisissez ceci pour ce TP !
  - Interne : le projet est accessible par quiconque se connecte sur le GitLab de l’université (donc fermé aux personnes extérieures à l’université).
  - Public : le projet est visible par tout le monde.
- Vous pouvez ignorer l’URL du projet, que vous pouvez laisser par défaut. (Si la fenêtre demande de le remplir, dans « Choisissez le groupe ou l’espace de nommage où vous souhaitez créer ce projet. », cherchez votre identifiant et sélectionnez-le.)
- Tout en bas, décochez la case « Initialiser le dépôt avec un README », afin de bien créer un nouveau référentiel public git entièrement vide.
Fenêtre Détails : une fois la validation faite, vous êtes désormais sur la page de votre nouveau projet. L’interface comprend une barre de navigation à gauche, et une grande zone sur le reste de l’écran. Par défaut, vous êtes dans la fenêtre « Détails », qui affiche pour l’instant « Le dépôt de ce projet est vide », ainsi que les instructions utiles pour une utilisation en ligne de commande.

1.2. Première utilisation de git

Un projet GitLab permet de faire un grand nombre de choses, mais fournit comme service principal la possibilité d’héberger un référentiel public (aussi appelé un dépôt git), au sein duquel sont rangés et versionnés tous les fichiers du projet.

Figure 1. Clonage et utilisation d’un référentiel

Voyons maintenant comment ajouter un fichier au référentiel public de votre projet GitLab.

Il est possible de créer des référentiels publics git sans utiliser GitLab, mais pour ce TP nous allons nous concentrer sur GitLab.

Configuration de git : Ouvrez un terminal, et configurez git en renseignant votre identité et votre éditeur de texte favori de la manière suivante :
- git config --global user.name "Prénom Nom"
- git config --global user.email "monemail@etu.univ-nantes.fr"
- git config --global core.editor "geany" (si vous souhaitez utiliser geany comme éditeur de texte par défaut (autres options : gedit, kate, vi…))
Cloner votre projet :
1. Dans la page GitLab de votre projet, trouvez le bouton bleu Code visible tout en haut à droite de la page. En cliquant dessus, vous avez accès à deux adresses permettant de cloner votre référentiel de deux manières différentes : par SSH ou par HTTPS. Pour le moment, copiez l’adresse disponible dans Cloner avec HTTPS.
2. Ouvrez un terminal et naviguez (avec cd) jusque dans un répertoire dans lequel vous souhaitez travailler. Effectuez la commande git clone suivie de l’adresse HTTPS que vous avez copiée depuis votre projet GitLab. Vous devez saisir votre identifiant et votre mot de passe GitLab. L’outil git va normalement afficher warning: warning: Vous semblez avoir cloné un dépôt vide., ce qui est normal puisque votre dépôt est vide.
Structure d’un référentiel local : Suite au clone, vous avez désormais un nouveau répertoire sur votre machine, qui porte normalement le même nom que votre projet Gitlab. Ce répertoire contiendra toujours à la fois votre copie de travail et votre référentiel local, ce dernier étant pour le moment une copie du référentiel public que vous avez créé sur Gitlab. Plus précisément, pour un projet appelé monprojet, le répertoire obtenu sera structuré de la manière suivante :
```
monprojet       ← répertoire obtenu suite au 'git clone'
├── .git        ← répertoire caché contenant le référentiel local
└──             ← contenu de votre copie de travail (pour le moment vide)
```
Allez dans ce répertoire (avec cd monprojet) et constatez avec ls qu’il apparaît… vide. C’est tout à fait normal car (1) votre copie de travail est vide, et (2) le répertoire .git est un répertoire caché (visible avec la commande ls -a). Notez que vous n’aurez jamais besoin de toucher au répertoire .git.
Ajout d’un fichier au référentiel : Ouvrez un éditeur de texte, écrivez un texte de votre choix à l’intérieur (« Hello world » par exemple), et sauvegardez-le sous le nom premierfichier dans votre copie de travail. Ensuite ouvrez un terminal et entrez les commandes suivantes :
1. git status vous permet de demander à git quelle est la situation, et il répond alors qu’il y a un fichier non suivi appelé premierfichier dans la copie de travail. L’affichage ressemble en principe à :

Sur la branche main

Aucun commit

Fichiers non suivis:
  (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé)
	premierfichier

aucune modification ajoutée à la validation mais des fichiers non suivis sont présents (utilisez "git add" pour les suivre)

git stage premierfichier vous permet d’indiquer à git que vous avez l’intention soit d’ajouter au référentiel local un nouveau fichier appelé premierfichier (s’il n’existait pas déjà), soit d’enregistrer dans le référentiel local les modifications faites à ce fichier (s’il existait déjà). Notez qu’on peut appeler git stage autant de fois que nécessaire pour ajouter plusieurs fichiers d’un coup au référentiel local.
si vous faites git status à nouveau, vous pouvez constater qu’il considère désormais le fichier ajouté comme un nouveau fichier, ce qui signifie que le fichier est prêt à être enregistré dans le référentiel local.
git commit -m "mettre un message pertinent ici" vous permet d’effectuer un commit, c’est à dire d’enregistrer véritablement dans le référentiel local tout ce que vous avez préparé avec git stage précédemment.
À ce stade, si vous effectuez git status vous voyez que git a validé les changements et donc qu’il ne considère plus votre fichier comme un nouveau fichier : il a bien été ajouté au référentiel local. Vous pouvez également faire git log pour afficher tous les commits réalisés jusqu’ici (si le log est trop grand pour la fenêtre du terminal, appuyez sur q pour quitter).
enfin, git push vous permet d’envoyer au référentiel public distant (ici, le GitLab de l’université) tous les commits que vous avez réalisé dernièrement, et qui sont pour le moment uniquement dans le référentiel local. Il vous faudra saisir à nouveau vos identifiants.
Une fois tout cela fait, rafraîchissez la page Web du GitLab de votre projet dans votre navigateur, et constatez qu’elle affiche désormais votre dernier commit, ainsi que la liste des fichiers présents sur le référentiel public.
1. Ajout d’un README : il est d’usage de mettre dans un référentiel un fichier nommé README.md qui donne des informations sur le projet. L’extension .md correspond au format Markdown. Effectuez à nouveau les actions de la question précédente Ajout d’un fichier au référentiel mais, cette fois-ci, pour ajouter un fichier nommé README.md et contenant le texte que vous souhaitez pour décrire votre projet. Ensuite, rafraîchissez à nouveau la page Web de votre projet sur GitLab, et constatez que par défaut GitLab affiche le contenu du fichier nommé README.md s’il existe à la racine du référentiel.
2. Ajout d’un .gitignore : il est également d’usage d’ajouter un fichier nommé .gitignore à la racine du référentiel, afin d’indiquer à git quels fichiers on ne souhaite jamais envoyer sur le référentiel public. C’est particulièrement utile pour être certain de ne pas commiter par erreur des fichiers produits par un compilateur (par exemple les fichiers .js produits par TypeScript). Chaque ligne d’un fichier .gitignore doit contenir un motif qui décrit un ensemble de fichiers interdits (par exemple *.js pour interdire tous les fichiers .js).
Effectuez à nouveau les actions de la question précédente Ajout d’un fichier au référentiel mais, cette fois-ci, pour ajouter un fichier nommé .gitignore (ne pas oublier le point initial) et contenant pour unique ligne *.js. Cela signifie que tous les fichiers .js seront ignorés, donc non suivis par git.
Pour tester votre fichier .gitignore, créez un fichier hello.js dans votre copie de travail, et constatez qu’il est ignoré par git status ou git stage.

Vous savez désormais comment utiliser un référentiel public sur GitLab, et comment utiliser git pour y envoyer des données 🎉

1.3. Synchroniser plusieurs référentiels locaux à l’aide d’un référentiel public.

Il est parfaitement possible de cloner plusieurs fois un même référentiel public git, par exemple si différentes personnes travaillent sur un projet depuis plusieurs machines différentes. Chaque personne travaillera alors sur son propre référentiel local obtenu en clonant le référentiel public distant. Dans cette situation, on voudra non seulement pouvoir envoyer des modifications au référentiel public distant (avec git push comme vu précédemment), mais on voudra également pouvoir récupérer les changements réalisés entre temps sur le référentiel public distant (avec git pull, voir ci-après) par les autres personnes.

1.3.1. Récupérer les changements des autres clones

Pour cette partie nous allons créer un 2e référentiel local sur la même machine que le 1er référentiel local, ce qui en pratique est peu utile, mais qui va permettre de comprendre comment synchroniser deux référentiels locaux, où qu’ils soient, avec un référentiel public.

Figure 2. Synchronisation de plusieurs clones

Création d’un 2e référentiel local :
1. préparez un nouveau répertoire, ouvrez un terminal et allez dans ce répertoire avec cd.
2. suivez à nouveau les consignes « Cloner votre projet » de la partie précédente pour obtenir un nouveau clone dans ce nouveau répertoire. Observez que ce clone contient la toute dernière version des fichiers du référentiel public, ce qui comprend les fichiers ajoutés via le 1er clone.
Commit d’un changement via le 2e clone : Dans ce nouveau clone de votre référentiel public, modifiez le fichier premierfichier créé précédemment, puis envoyez la modification sur son référentiel local (avec git stage et git commit) puis sur le référentiel public (avec git push) comme précédemment. Observez que ce changement est bien visible sur l’interface Web de GitLab.
Tentative de commit et push via le 1er clone : Retournez dans le 1er clone que vous aviez réalisé dans la partie précédente. Dans ce 1er clone, modifiez le fichier README.md, puis envoyez là aussi cette modification sur son référentiel local (avec git stage et git commit) puis sur le référentiel public (avec git push) comme précédemment) Mais patatras, lorsque vous faites git push, vous avez un message d’erreur vous indiquant que vous ne pouvez pas faire de modification avant d’avoir récupéré les changements qui ont eu lieu entre temps sur le référentiel public, via le 2e clone. Ce message peut ressembler à
```
To gitlab.univ-nantes.fr:(votre-projet.git)
 ! [rejected]        main -> main (fetch first)
error: impossible de pousser des références vers 'gitlab.univ-nantes.fr:(votre-projet.git)'
astuce: Updates were rejected because the remote contains work that you do not
astuce: have locally. This is usually caused by another repository pushing to
astuce: the same ref. If you want to integrate the remote changes, use
astuce: 'git pull' before pushing again.
astuce: See the 'Note about fast-forwards' in 'git push --help' for details.
```
Récupération des changements distants sur le 1er clone : Toujours dans le 1er clone, entrez la commande git pull pour demander à récupérer tous les changements qui ont eu lieu sur le référentiel public. Un éditeur de texte va alors s’ouvrir pour vous demander d’écrire un message de fusion (car il faut fusionner le commit réalisé sur le 1er clone avec le commit réalisé avec le 2e clone), mais vous pouvez laisser le message tel quel et fermer la fenêtre. (Si ce n’est pas un éditeur de texte avec une interface graphique qui s’ouvre mais une application dans le terminal, entrez Ctrl+X pour sauvegarder et quitter sans modifications.) Observez que vous avez bien récupéré le changement réalisé sur premierfichier.
Nouvelle tentative de push : on peut maintenant tenter à nouveau de faire git push, et constater qu’il n’y a cette fois-ci pas de message d’erreur : le commit du 1er clone a bien été envoyé !
Récupération des changements distants sur le 2e clone : enfin, on peut se rendre à nouveau dans le 2e clone, et effectuer git pull pour récupérer les derniers changements. Une fois cela fait, les deux référentiels locaux sont à nouveau complètement identiques et synchronisés avec le référentiel distant.

1.3.2. Gérer une situation de conflit

Il peut arriver que deux clones d’un même référentiel distant voient arriver des modifications concurrentes sur la même zone d’une même fichier. Dans ce cas, on peut voir apparaître un conflit. Voyons comment peut apparaître une situation de conflit, et comment la résoudre.

Commit d’un changement via le 1er clone : dans le 1er clone, modifiez une ligne de votre fichier README.md, et retenez bien la ligne modifiée. Puis effectuez un stage, un commit et un push de ce changement vers le référentiel distant.
Commit d’un changement via le 2e clone : dans le 2e clone, effectuez une modification différente de la même ligne que celle modifiée via le 1er clone. Puis effectuez seulement un stage et un commit, afin de seulement enregistrer ce changement dans le référentiel local.
Récupération des changements distants sur le 2e clone − et conflit ! : dans le 2e clone, tentez de récupérer la modification distante avec git pull… et patatras, nouveau message d’erreur: CONFLIT! git ne sait pas comment gérer le fait que deux commits ont simultanément souhaité changer la même ligne, et il a donc besoin que nous lui disions quoi faire pour résoudre cela.
Découverte du conflit sur le 2e clone : ouvrez le fichier README.md du 2e clone dans un éditeur de texte, et constatez qu’il contient un morceau de texte étrange prenant cette forme :
```
<<<<<<< HEAD
ligne écrite après le commit du 1er clone
=======
ligne écrite après le commit du 2e clone
>>>>>>> e7916201c61d53d861d54cc3ec1e9de8604eedd9
```
Cette notation signifie qu’il existe un conflit à résoudre à cet endroit. D’abord entre <<<<<<< et =======, git nous indique quelle serait la ligne d’après le commit effectué dans le 1er clone. Puis entre ======= et >>>>>>>, il nous indique quelle serait la ligne d’après le commit effectué dans le 2e clone. Il faut ici faire un choix !
Résolution du conflit sur le 2e clone : pour résoudre le conflit, on va à l’aide d’un éditeur de texte modifier le bloc de texte de conflit vu au point précédent (donc depuis <<<<<<< jusqu’à >>>>>>>) afin de ne garder que la ligne que l’on souhaite finalement garder. Si on reprend l’exemple si dessus, et si on pense que le 1er clone avait raison dans son changement, on remplace tout le bloc de conflit par :
```
ligne écrite après le commit du 1er clone
```
Puis on enregistre le fichier, et enfin on va simplement effectuer comme d’habitude git stage, git commit et git push du fichier résultant. La nouvelle version du fichier est désormais enregistrée sur le référentiel public, et le conflit est résolu !

Ne pas oublier ensuite de faire un git pull sur le 1er clone, pour synchroniser les deux référentiels locaux.

On rappelle que le travail avec plusieurs clones d’un même référentiel public est particulièrement pertinent pour le travail en équipe : par exemple chaque étudiant⋅e d’un binôme peut garder son propre référentiel local sur son ordinateur, et peut à l’aide de git et d’un référentiel public GitLab synchroniser ses fichiers avec ceux de sa ou son collègue.

1.4. Activation de la connexion par SSH dans GitLab

Vous avez pu constater qu’il était assez agaçant de devoir toujours saisir son mot de passe lorsqu’on effectue git pull ou bien git push. La cause de ce problème est le fait d’avoir effectué un clone via le protocole HTTPS, et non avec le protocole SSH (voir partie « Première utilisation de git »).

Pour ne plus avoir à saisir son mot de passe, il faut sécuriser la communication avec GitLab avec la génération d’une clé de chiffrement sur votre compte Linux, et il faut confier à GitLab les informations sur votre clé. Nous allons utiliser ici un chiffrement dit asymétrique, constitué d’une clé privée (qui, comme son nom l’indique, est absolument privée et doit rester sur votre ordinateur) et d’une clé publique, que vous pouvez transmettre à qui le souhaite, et donc ici au serveur GitLab de l’université.

Génération d’une clé de chiffrement : Ouvrez un terminal, et effectuez la commande ssh-keygen. On vous pose alors trois questions :
1. D’abord choisir l’emplacement du fichier − appuyez juste sur la touche ⏎ (touche ENTRÉE) pour garder l’emplacement par défaut.
2. Puis on vous demande une phrase de passe (Enter passphrase) pour sécuriser votre clé, mais c’est optionnel. Appuyez sur ⏎ (touche ENTRÉE) pour ne pas avoir de phrase de passe.
3. Enfin on vous demande de confirmer votre phrase de passe (Enter same passphrase again), appuyez à nouveau sur ⏎ (touche ENTRÉE).
4. Voilà, vous avez une clé de chiffrement prête à utiliser sur votre compte Linux université !
Configuration du compte GitLab :
1. Dans un terminal, entrez la commande geany ~/.ssh/id_rsa.pub pour ouvrir votre clé publique dans un éditeur de texte, ici geany (on suppose que l’emplacement par défaut lors de la création de la clé était ~/.ssh/id_rsa.pub). Ne la modifiez pas et gardez cette fenêtre ouverte.

il est possible que le fichier soit ~/.ssh/id_ed25519.pub et non id_rsa.pub, auquel cas remplacez cet identifiant dans le reste de ce TP.

c’est bien la clé publique (~/.ssh/id_rsa.pub) qu’il faut copier, et certainement pas la clé privée (~/.ssh/id_rsa) ! Par définition, ⚠️ votre clé privée doit rester privée ⚠️, c’est-à-dire jamais transférée à qui que ce soit (ni même sur une autre machine : pour utiliser Git sur deux machines, il suffit de recréer une autre clé sur l’autre machine, et de suivre cette procédure).

Dans l’interface Web de GitLab, cliquez sur le portrait tout en haut à droite, puis sur Préférences. Vous êtes désormais dans les paramètres de votre compte personnel GitLab.
Dans le volet de gauche, cliquez sur SSH Keys. Vous êtes face à un formulaire pour ajouter une clé de chiffrement à GitLab (ou cliquer sur « Ajouter une nouvelle clé » si le formulaire ne s’affiche pas directement).
Copiez tout le contenu du fichier ~/.ssh/id_rsa.pub ouvert précédemment, et puis collez-le dans le champ « Clé » du formulaire GitLab d’ajout de clé de chiffrement. Puis cliquez sur « Ajouter une clé », et voilà.
1. Tester la connexion SSH : Refaites l’exercice « Cloner votre projet » présenté précédemment dans le TP, et cette fois-ci effectuez un clone via l’adresse SSH. Vous pouvez constater que vous n’avez plus à saisir de mot de passe, car la connexion se fait automatiquement via votre clé de chiffrement.

1.5. (optionnel) Quelques autres fonctionnalités GitLab

GitLab ne permet pas uniquement la création d’un référentiel public, et fournit un certain nombre de fonctionnalités. Voyons deux possibilités intéressantes pour un projet GitLab : l’ajout de collaborateurs, et la gestion des tickets.

1.5.1. Ajout de collaborateurs

Pour cette partie il est nécessaire d’être en binôme. Le but est d’ajouter sa ou son co-équipier comme collaborateur du projet GitLab créé précédemment, afin de lui donner l’autorisation de modifier les fichiers présents sur le référentiel.

Initialisation des comptes GitLab : avant toute chose, il est nécessaire que chaque membre du binôme se soit connecté⋅e au moins une fois sur l’interface Web de GitLab, afin d’avoir initialisé chaque compte GitLab dans la base de données du GitLab de Nantes Université. Si c’est déjà fait, passez à l’étape suivante.
Ajout d’un collaborateur :
1. Dans le panneau de gauche, allez dans le menu Gestion Membres ;
2. Cliquez sur le bouton Inviter des membres
3. Dans le champ de texte « Nom d’utilisateur, nom ou adresse de courriel », saisissez le nom de la personne à ajouter comme collaborateur, et sélectionnez la dans la liste déroulante qui apparaît.
4. Dans le champ « Sélectionnez le rôle maximal », vous avez le choix entre plusieurs rôles (chaque rôle ajoute des droits au rôle précédent) :
  - Invité : la personne aura le droit d’accéder à la page du projet et de cloner le projet, mais ne pourra pas modifier les fichiers.
  - Rapporteur : la personne pourra changer quelques options supplémentaires, mais ne pourra toujours pas modifier les fichiers.
  - Développeur : la personne pourra modifier les fichiers, mais ne peut pas modifier les paramètres avancés du projet GitLab − choisissez ce rôle !
  - Chargé de maintenance : la personne peut presque tout faire, sauf supprimer le projet !
5. Enfin, cliquez sur « Inviter » pour terminer.

La personne ajoutée peut désormais cloner le projet, effectuer des modifications et les push vers le référentiel public du projet 🎉

1.5.2. Gestion de tickets

Un projet GitLab permet de gérer des tickets (en anglais, issues), à savoir des informations sur les tâches à effectuer sur le projet. Un ticket peut être un bug observé sur le logiciel et qu’il faut corriger, ou bien peut décrire une nouvelle fonctionnalité proposée pour le logiciel, ou encore peut simplement indiquer une tâche à effectuer pour la gestion de projet.

Notez que n’importe qui ayant accès à un projet GitLab peut y ajouter des tickets. Un projet public peut donc recevoir des tickets de tout le monde, ce qui permet aux utilisateurs de communiquer à des développeurs quels problèmes ils ont rencontré avec leur logiciel.

Création d’un ticket :
1. Dans le panneau de gauche, allez Tickets puis dans Liste. Comme il n’y a aucun ticket pour le moment, le panneau central est vide.
2. Cliquez sur "Nouveau ticket", et un formulaire s’affiche. Inventez un titre (par exemple "Problème avec XXX") et une description (ex. "J’ai un problème lorsque je fais XXX") pour le ticket, puis faites "Submit ticket". Le ticket est alors créé, et vous êtes désormais sur la page du ticket.
Ajout d’un commentaire :
1. À nouveau, dans le panneau de gauche, allez Tickets puis dans Liste, et constatez que votre ticket est présent. Cliquez dessus pour de nouveau aller dans la page du ticket.
2. Sous la description du ticket, une boîte est disponible pour ajouter un commentaire. Cela permet d’ajouter de nouvelles informations, ou de discuter entre développeurs sur la meilleure voie à suivre pour résoudre le problème. Dans cette boîte, écrivez un message et faites Commenter.
Fermeture d’un ticket : lorsque la tâche à effectuer a bien été faite, il faut alors fermer le ticket associé à cette tâche. Pour cela, cliquer sur le bouton "Close issue", et le ticket n’apparaîtra alors plus dans la liste de tickets.

2. Exploration d’un projet GitLab existant

Dans la partie précédente on a vu comment utiliser GitLab et git pour travailler sur votre propre projet. Nous allons maintenant observer un projet GitLab existant, et voir comment proposer des changements au projet sans pour autant avoir été ajouté collaborateur.

2.1. Récupération d’un projet existant

Rendez-vous à l’adresse https://gitlab.univ-nantes.fr/gl/developpement/pokemonBattle et parcourez les différentes pages relatives au projet.

Observez d’abord attentivement :
- Le fichier README.md affiché en première page et guidant les utilisateurs;
- La page Tickets (issues) permettant de soumettre un bug ou une amélioration et consulter la liste des tâches en cours et à venir.
- La page Code > Dépôt (repository) permettant de naviguer dans l’arborescence des fichiers du projet
- Les pages Code > Validation (commits), Code > Branches (branches) et Code > Graphe du dépôt (graph) permettant de consulter l’historique des commits et les changements apportés dans chaque branche de développement.
Question : À partir de votre exploration du site, quels ont été les changements apportés par le commit e662b687 ?
Effectuez un clone de ce projet sur votre ordinateur.
Ouvrez le dossier téléchargé dans Visual Studio Code.

Le projet (incomplet) que vous venez d’importer via git est un simulateur de combats de Pokémon. Un Pokémon est un montre virtuel caractérisé entre autres par un nom, un nombre de points de vie, une célérité, une puissance d’attaque et une résistance aux coups. Chaque joueur du duel (appelé dresseur) possède une liste de monstres (Pokémon) qui s’affrontent au tour par tour dans une arène. Au début de la partie, chaque joueur fait combattre le premier monstre de sa liste. Le Pokémon le plus rapide (possédant la plus grande célérité) frappe alors en premier. Si son adversaire survit (nombre de points de vie strictement positif), il peut à son tour attaquer son adversaire. Lorsque l’un des deux Pokémon ne possède plus de points de vie, il est déclaré K.O. Son propriétaire (joueur) le remplace par le deuxième Pokémon de sa liste et ainsi de suite. Le premier joueur ne possédant plus de Pokémon en état de combattre est déclaré perdant.

2.2. Développement et premier commit

il est possible que ce code ne fonctionne plus sur les machines actuelles du département. Voyez avec votre enseignant⋅e le cas échéant.

Observez les différents fichiers TypeScript importés dans votre clone, en particulier les interfaces, les descriptions des fonctionnalités et le fichier principal main.ts.
Trouvez le ticket nommé "Attack is not working " sur le site GitLab du projet.
Ouvrez le fichier pokemon.ts et complétez la fonction attack pour résoudre ce bug. Lors d’une attaque, le nombre de points de vie retirés est calculé de la manière suivante :

Damage = 5 * (Force/Armor) + 2

Un Pokémon ne peut voir ses points de vie descendre en dessous de zéro, donc si le dommage est supérieur aux points de vie, alors les points de vie deviennent 0.
Une fois le bug résolu et vérifié, vérifiez la bonne exécution du code, effectuez un commit de vos changements via les commandes git stage et git commit. Constatez la prise en compte de votre commit dans votre clone via la commande git log (touche q pour quitter).
Vous pouvez dès lors essayer d’effectuer un git push de votre changement… mais comme vous n’êtes pas collaborateur du projet, l’accès va vous être refusé ! Réglons cela dans la partie suivante.

2.3. Effectuer une bifurcation (fork en anglais)

Quand on n’est pas collaborateur sur un projet GitLab, une possibilité est d’effectuer une copie du projet GitLab pour travailler dessus comme on le souhaite. Faire une telle copie s’appelle effectuer une bifurcation du projet (en anglais, fork).

Création du fork : Allez sur la page GitLab du projet pokemonBattle, et cliquez sur le bouton en haut à droite Bifurcations. Après quelques secondes, vous êtes désormais face à la page d’accueil d’un nouveau projet GitLab, qui est en fait une copie conforme du projet GitLab pokemonBattle. Mais vous êtes désormais propriétaire de cette copie, vous pouvez donc effectuer toutes les modifications que vous souhaitez !
Configuration du clone : Il faut désormais reconfigurer votre clone afin d’utiliser ce nouveau projet GitLab plutôt que l’ancien.
1. Commencez par cliquer sur le bouton bleu Clone en haut à droite, et copiez l’adresse du nouveau référentiel public.
2. Ouvrez un terminal, rendez vous dans le répertoire de votre clone de pokemonBattle, et faites la commande suivante pour désormais pointer vers le référentiel public de votre copie du projet GitLab : git remote set-url origin NOUVELLE_ADRESSE.
Nouvelle tentative de push : Enfin, tentez à nouveau de faire un push, et constatez que votre commit a bien été enregistré et est visible dans la page GitLab de votre bifurcation !

2.4. Effectuer une demande de fusion (merge request en anglais)

Après avoir effectué des changements dans le projet pokemonBattle, et après avoir push ces changements dans votre bifurcation, vous pouvez avoir envie de proposer vos changements (autrement dit, l’ensemble de vos commits) auprès des propriétaires du projet originel pokemonBattle, pour qu’ils puissent en bénéficier. Pour cela on peut effectuer une demande de fusion (merge request en anglais).

Allez sur la page GitLab de votre bifurcation.
Dans le panneau de gauche, cliquez sur "Demandes de fusion", puis cliquez sur le bouton "Nouvelle demande de fusion"
Vous devez alors choisir quelle branches il faut fusionner. Comme nous n’avons pas vu le concept de branche git dans ce TP, nous n’avons qu’une seule branche appelée master. On peut donc choisir master comme "Source branch", puis cliquer sur "Compare branches and continue"
Vous êtes face au formulaire de demande de fusion. Vous pouvez :
- Saisir un titre pertinent (ex. "Résout le bug XXX"),
- Saisir une description (ex. "Cette fusion résout le problème XXX en changeant YYY et ZZZ").
- Visualiser l’ensemble des changements proposés par cette demande de fusion ; pour cela, cliquer sur l’onglet Changes en bas de la page. Les lignes en rouges sont les lignes retirées, et les lignes en vert sont les lignes ajoutées.
Enfin, cliquez sur "Submit demande de fusion" − et voilà, le propriétaire du projet pokemonBattle va recevoir une notification comme quoi quelqu’un lui propose une modification sur son projet, qu’il pourra choisir d’accepter ou non !

Nous utiliserons le principe de bifurcation et de demande de fusion pour le rendu du TP projet qui sera demandé à la fin de cette UE.

2.5. (Bonus) Développement d’une fonctionnalité supplémentaire

Le développement de notre simulateur avance et les premiers utilisateurs sont enthousiastes. Cependant, de nombreux retours vous demandent d’ajouter la prise en compte des types de Pokémon lors du calcul de combat. Par exemple, une attaque d’un Pokémon feu contre un Pokémon eau sera très inefficace (dégâts divisés par 2) tandis qu’un Pokémon végétal recevra un montant accru de dommages (x2).

Un tableau des rapports de force (coefficients) est proposé dans le ticket nommé Improve battle system.

Retrouvez le ticket qui décrit cette nouvelle fonctionnalité, et le tableau de coefficients proposé.
Modifiez votre code source pour prendre en compte les ratios de dégâts. N’hésitez pas à proposer votre solution avant de vous lancer dans son implémentation. Nous ne considérerons dans un premier temps que les types eau, feu et plante.
Effectuez un/des commit(s) pendant votre développement et testez le nouveau comportement à l’aide d’affichages ou du débogueur, et effectuez un git push pour enregistrer vos commits dans votre bifurcation sur GitLab.

3. Résumé et informations utiles

3.1. Rappel des commandes git les plus courantes

Récupération d’un référentiel public, et création d’un référentiel local : git clone "votre adresse"
Récupération des derniers commits du référentiel public : git pull
Pour effectuer un commit :
1. Ajout des fichiers sur la scène : git stage fichier1 [fichier2 …] (note : on peut appeler git stage autant de fois que nécessaire avant un git commit)
2. Déclenchement du commit : git commit -m "Message de commit"
Envoi de vos commits sur le référentiel public : git push
Création d’une nouvelle branche de travail : git checkout -b nomDeBranche