TP - GitLab

Ce TP a pour objectif d’utiliser le gestionnaire de version git et l’une de ses forges nommée 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 à l’université, pour tous vos enseignements et pas seulement en IDL ! 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 à l’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 l’université. Vous êtes ainsi connecté sur la forge, ce qui vous permet de vous promener au sein de tous les projets publics existant. 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 GitLab qui est installé à 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 "Create blank project". 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 Visibility Level (en français, 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 de tous.
- Vous pouvez ignorer l'URL du projet, que vous pouvez laisser par défaut.
- Tout en bas, décochez la case "Initialize repository with a 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 la liste des fichiers présents dans la dernière version du référentiel, ainsi que le contenu du fichier README du référentiel s’il est présent. Mais pour le moment, le projet est vide, donc rien de très intéressant 🙂.

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 "gedit"
Cloner votre projet :
1. Dans la page GitLab de votre projet, trouvez le bouton bleu Clone 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 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é depuis votre projet GitLab. Vous devez saisir votre identifiant et votre mot de passe GitLab. L’outil git va alors peut-être vous répondre warning: Vous semblez avoir cloné un référentiel vide., ce qui est normal.
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)
```
Ouvrez ce répertoire et constatez… qu’il apparait 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 faites 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.
2. 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.
3. 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.
4. 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.
5. à 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 (appuyez sur q pour quitter).
6. 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.
7. Une fois tout cela fait, rafraichissez la page GitLab de votre projet, et constatez qu’il affiche désormais votre dernier commit, ainsi que la liste des fichiers présents sur le référentiel public !
Ajout d’un README : il est d’usage de mettre dans un référentiel un fichier nommé README qui donne des informations sur le projet. 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 rafraichissez à nouveau la page 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.
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 les fichiers .js).
1. 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 !) et contenant pour unique ligne *.extensioninterdite.
2. Pour tester votre fichier .gitignore, créez un fichier hello.extensioninterdite 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 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 !
Récupération des changements distants sur le 1er clone : Toujours dans le 1er clone, effectuez le 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. 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 chose, et il a donc besoin que nous lui disions quoi faire pour résoudre cela.
Découverte du conflit sur le 2e clone : ouvrez README.md 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 !

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. (optionnel) Activation du clone 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é.

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 − faites juste entrée pour garder l’emplacement par défaut.
2. Puis on vous demande une passphrase pour sécuriser votre clé, mais c’est optionnel. Faites entrée pour ne pas avoir de passphrase.
3. Enfin on vous demande de confirmer votre passphrase, faites entrée à nouveau.
4. Voilà, vous avez une clé de chiffrement prête à utiliser sur votre compte Linux université !
Configuration du compte GitLab :
1. Dans un terminal faites la commande gedit ~/.ssh/id_rsa.pub pour ouvrir votre clé publique dans un éditeur de texte. Ne la modifiez pas et gardez cette fenêtre ouverte.
2. Dans GitLab, cliquez sur le portrait tout en haut à droite, et cliquez sur Paramètres. Vous êtes désormais dans les paramètres de votre compte personnel GitLab.
3. Dans le volet de gauche, cliquez sur Clefs SSH. Vous êtes face à un formulaire pour ajouter une clé de chiffrement à GitLab.
4. Copiez tout le contenu du fichier ~/.ssh/id_rsa.pub ouvert précédemment, et collez le contenu dans le champ Key du formulaire GitLab d’ajout de clé de chiffrement. Puis cliquez sur Ajouter une clef, et voilà !
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 via votre clé de chiffrement !

1.5. Quelques autres fonctionnalités GitLab

GitLab ne permet pas juste 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é au moins une fois sur l’interface GitLab, afin d’avoir initialisé chaque compte GitLab dans la base de données. 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 ou adresse de messagerie", 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 un rôle", vous avez le choix entre plusieurs rôles (chaque rôle ajoute des droits au rôle précédent) :
  - Guest : la personne aura le droit d’accéder à la page du projet et de cloner le projet, mais ne pourra pas modifier les fichiers.
  - Reporter : la personne pourra changer quelques options supplémentaires, mais ne pourra toujours pas modifier les fichiers.
  - Developer : la personne pourra modifier les fichiers, mais ne peut pas modifier les paramètres avancés du projet GitLab − choisissez ce rôle !
  - Maintainer : la personne peut presque tout faire, sauf supprimer le projet !
5. Enfin, cliquez sur "Ajouter au projet" 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 (ex. "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 Issues permettant de soumettre un bug ou une amélioration et consulter la liste des tâches en cours et à venir.
- La page Repository permettant de naviguer dans l’arborescence des fichiers du projet
- Les pages Commits, Branches et 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émons. 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émons 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

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 !
Une fois le bug résolu et vérifié, 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ésoud 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