tuto-git-gitlab/git-commande.md

+Voici une démo des principales commandes de git, à utiliser depuis un terminal. Pour **Windows**, utilisez le _Terminal_ appelé ``Windows Powershell``.
+
+Notez que C.E. Bichot a rédigé un tuto sur l'usage de _git_ en mode commande, disponible en suivant [ce lien](https://gitlab.ec-lyon.fr/cbichot/git-intro). 
+
+**Configuration de git** (à faire une fois pour toute)
+```bash
+>> git config --global color.ui true
+>> git config --global user.name "votre_pseudo"
+>> git config --global user.email moi@email.com
+>> git config --global core.editor geany                                       #(for Linux if installed)
+>> git config --global core.editor "/App.../Sublime\ Text.app/.../bin/subl -w" #(for Mac if installed)
+>> git config --global core.autocrlf true                                      #(for Windows)
+>> git config --list
+>> cat ~/.gitconfig
+```
+
+**git clone / status / log**
+```bash
+>> git clone https://gitlab.ec-lyon.fr/sderrode/helloworld.git
+>> cd helloworld
+>> git status
+>> git log
+```
+Il s'agit ici du clonage d'un projet existant sur votre espace **gitlab**.
+
+**Modification d'un fichier existant**
+```bash
+>> subl readme.md                               #(modification du fichier)
+>> git status
+>> git commit -a -m "modification de readme.md"
+>> git status
+>> git log
+```
+
+**Création d'un fichier et ajout à git**
+```bash
+>> touch prog.py                          #(création d''un nouveau fichier vide)
+>> subl prog.py                           #(écriture d''un programme dans le fichier)
+>> python prog.py
+>> git status
+>> git add prog.py                        #(suivi du fichier par git)
+>> git add -A                             #(suivi de tous les nouveaux fichiers )
+>> git commit -a -m "ajout d'un fichier"
+>> git status
+>> git log
+```
+On peut utiliser ce procédé pour ajouter un fichier ``.gitignore`` sur la racine du projet.
+
+
+**Différence entre 2 commit**
+```bash
+>> git diff HEAD^ HEAD README.md  #(entre l''avant dernier et le dernier commit)
+```
+On peut remplacer ``HEAD^`` et ``HEAD`` par deux numéros de commit.
+
+**Revenir en arrière**
+```bash
+>> git reset --hard 82f5     #(attention suppression des commit les plus récents!)
+>> git checkout 1ce87820b4b1 #(bref saut dans un commit précédent)
+>> git log
+>> ls
+>> git checkout master (on revient dans l''état initial)
+>> git log
+>> ls
+```
+
+**Publication vers gitlab et mise à jour depuis gitlab**
+```bash
+>> git status
+>> git push    #(publication vers gitlab de tous les nouveaux commit)
+>> git pull    #(récupération des changements publiés par d'autres)
+```
+
+Si un collègue du projet à mis à jour le dépôt **gitlab**, alors il faut fusionner ces modifications avec vos propres travaux, localement sur votre machine. Avant de lancer la commande, pensez à commiter vos propres changements. Si la fusion pose problèmes (vous avez travaillé sur le même bout de code et vos corrections ne sont pas fusionable de manière automatique), alors git vos informe de la procédure manuelle à suivre.
+
+**Création d'une branche**
+Les branches sont essentiellement utilisées pour tester une idée sans perturber le projet. Si vous validez cette idée, alors il devient possible de fusionner la branche avec la branche principale:
+```bash
+>> git branch essai                                #(on créé une nouvelle branche essai
+>> git branch
+>> git checkout essai                              #(on bascule vers cette branche)
+>> touch ALIRE.tx
+>> subl ALIRE.tx
+>> git add ALIRE.tx
+>> git commit -a -m "add file ALIRE.tx"
+>> ls
+>> git log
+>> git checkout master
+>> ls
+>> git merge essai -m "merge de la branche essai"  #(vous pouvez préciser un message qui explique le merge)
+>> ls
+>> git branch -d essai                             #(destruction de la branche après merge)
+```
+On peut très bien merger une branche et continuer son développement pour faire un second merge plus tard. On peut aussi publier la branche sur **gitlab** (pour l'instant elle ne reste que locale).
+
+**Tagger une version**
+```bash
+>> git tag -a v0.1 HEAD -m "my version 0.1"
+>> git tag                                  #(liste les tags)
+>> git push --tags                          #(envoi des tag sur le dépôt gitlab)
+```
+
+**Archiver une version**
+```bash
+>> git archive --format=tgz --prefix=git-0.1/ HEAD >git-0.1.tgz
+>> ls
+```

tuto-git-gitlab/git-fork.md

+[[TOC]]
+
+Comme tout tutoriel, ce document a besoin de vos retours pour s'améliorer! N’hésitez pas à m'envoyez un mail décrivant vos difficultés et, éventuellement, les solutions que vous auriez trouvées pour les contourner.
+
+Le déroulement de ce tutoriel a été enregistré sous forme vidéo : [git-fork tuto video](https://pedagogie1.ec-lyon.fr/mod/resource/view.php?id=18217).
+
+# Présentation de git 
+
+Ce mini tutoriel consiste en une présentation (très simplifiée) de l'usage du système de gestion de version appelé **git** (à prononcer  ``guite``). La présentation se limite aux usages que nous exploiterons durant les BEs de l'UE Informatique (en particulier: rendus de travail automatisés, pour les BE #3 et #5). 
+
+Il constitue néanmoins une introduction à un outil très utilisé dans le domaine du développement logiciel, et que vous pourriez utiliser à de nombreuses reprises dans votre scolarité (notamment dans les projets de développement en groupe tels que les PE, le PAi ou PAr), et au delà! En tout état de cause, il se justifie pleinement dans le cadre de la crise sanitaire que nous traversons, en proposant un outil collaboratif de travail très performant.
+
+> [wikipédia git](https://fr.wikipedia.org/wiki/Git "link to wikipedia git"): 'Il s'agit du logiciel de gestion de versions le plus populaire qui est utilisé par plus de douze millions de personnes.' (en 2016) 
+
+## Présentation succincte de git et gitlab
+**git** est un système de contrôle de version (*version control system*, ou VCS)
+
+- Un ensemble d'outils logiciels pour:    
+    - Mémoriser et retrouver différentes versions d'un projet.    
+    - Faciliter le travail collaboratif.    
+- Initialement développé par Linus Torvalds pour faciliter le développement du noyau Linux:    
+    - Logiciel libre / open source.    
+    - Disponible sur toutes les plates-formes.   
+
+*Remarque :* **git** est disponible par défaut sur les machines *Mac OS X* et *Linux*. S'il est absent de *Windows* (pour le savoir, lancez la commande *git* dans un Terminal), alors installez-le à partir de ce lien : [git-scm](https://git-scm.com/download/win).
+
+Il existe de très nombreux tutoriels sur **git** (vidéo ou slides), complets mais qui peuvent rapidement paraître ardus pour les débutants (*p. ex.* [slides de Robin Passama](https://romainlebreton.github.io/ProgWeb-CoteServeur/assets/initiation%20GIT_IUT.pdf)). La maîtrise de **git** n'est en aucun cas indispensable pour les BEs. Par contre, maîtriser la suite de ce tuto l'est pour le rendu de vos travaux évalués (BE #3 et #5)!
+
+**gitlab** est une application web basée sur **git**.
+
+- Permet de gérer:    
+    - Le cycle de vie de projets git.    
+    - Les participants aux projets (rôles, groupes...). 
+    - La communication entre ces participants.    
+- Développée par une société privée, mais qui offre des services gratuits (dans notre cas, la version *GitLab Community Edition*).
+
+Dans le cadre des BEs, nous utiliserons le **gitlab** installé par la DSI sur les serveurs de l'École, accessible à cette [adresse](https://gitlab.ec-lyon.fr/users/sign_in). Il vous suffit de vous logger avec vos identifiants habituels de l'École pour accéder à votre espace **gitlab**. Pour l'instant votre espace de projets est sans doute vide, mais nous allons le peupler. Avant de poursuivre, veuillez copier en mémoire l'url de votre espace, c'est-à-dire le lien qui ressemblera à ça: *https://gitlab.ec-lyon.fr/xyyyyy* (mais avec votre propre loggin bien sûr).
+
+La démarche que nous allons maintenant décrire est résumée par ce diagramme:
+
+ 1. La première étape consiste à créer une copie (appelé ``fork`` dans le vocabulaire **gitlab**) de l'énoncé de BE sur votre espace **gitlab**.
+ 2. La seconde consiste à créer une copie du fork sur votre disque dur. C'est à cet endroit que vous rédigerez vos programmes pour répondre aux questions de l'énoncé. 
+ 3. La troisième étape consistera à mettre à jour le ``fork``. L'encadrant de TD viendra alors récupérer vos travaux sur votre espace **gitlab** pour évaluer votre travail personnel. 
+
+<center><img src="figures/Fork.png" style="width:50%"/></center>
+
+
+## 1. Fork (copie de projet) des énoncés de BE de INF-TC2
+
+Pour la démonstration, nous allons créer, sur votre espace **gitlab**, une copie du projet contenant l'énoncé du BE #3 de INF-TC2 ; cette opération s'appelle un ``fork`` et pourra être appliquée sur d'autres projets (en particulier le BE #5, et les BEs de INF-TC1, en fonction des consignes de vos encadrants). Suivez le guide...
+
+- Ouvrez la page https://gitlab.ec-lyon.fr/sderrode/INF-TC2-BE3. Vous observez le projet qui héberge l'énoncé du BE #3 sur le **gitlab** de l'École.    
+- Cliquez sur le bouton ``Fork``(en haut à droite de l'interface). Sélectionnez ensuite votre espace **gitlab** pour lancer la copie.
+
+En revenant sur votre espace **gitlab**, vous pouvez constater la présence de votre copie personnelle du projet. L'interface WEB **gitlab** ne permet pas de modifier facilement les fichiers et encore moins de programmer. Nous passons donc à l'étape suivante qui consiste à importer une copie locale du projet sur votre ordinateur.
+
+ <center><img src="figures/ForkSuccess.png" style="width:50%"/></center>
+
+### Important!
+**Important** Il vous faut paramétrer votre projet pour le rendre privé, mais permettre à votre encadrant de venir consulter votre travail. Pour cela, veuillez suivre scrupuleusement les étapes suivantes :
+
+ 1. Rendez-vous sur votre espace **gitlab** et sélectionnez votre projet.    
+ 1. Dans la barre de menu latérale à gauche de l'interface Web, sélectionnez l'icône représentant une roue crantée correspondant à ``Settings``. Dans le sous-menu ``Général``, appuyez sur le bouton ``Expand`` correspondant à la ligne : *Visibility, project features, permissions*. Dans *Project visibility*, sélectionnez ``Private`` (au lieu de ``Public``). N'oubliez pas de sauver les changements à l'aide du bouton qui se situe un peu plus bas.    
+ <center><img src="figures/Visibility.png" style="width:50%"/></center>   
+ 1. Toujours dans la barre de menu latérale à gauche de l'interface Web, sélectionnez maintenant le menu ``Members`` (juste au dessus de ``Settings``). Sélectionnez dans la liste déroulante de l'espace *Gitlab Members or Email address* votre encadrant, et donnez-lui le rôle de ``reporter`` (au lieu de ``Guest``). N'oubliez pas finalement d'inviter votre encadrant en cliquant sur le bouton ``Invite``.    
+ <center><img src="figures/AjoutEncadrant.png" style="width:50%"/></center>
+
+
+ Voilà, votre ``fork`` est paramétré
+
+## 2. Importation du projet sur votre machine
+
+- Téléchargez, installez et lancez l'application [Github Desktop](https://desktop.github.com/).    
+- Depuis la page de votre espace **gitlab**, cliquez sur l'icône ``Clone`` et copiez le lien ``Clone with HTTPS`` (qui ressemble à https://gitlab.ec-lyon.fr/xyyyyy/INF-TC2-BE3.git).    
+- Dans l'application ``Github Desktop``, sélectionnez l'option ``Clone a Repository from the Internet``, puis l'onglet ``URL`` (ou menu ``File``, ``Clone repository``). Copiez l'adresse précédemment mise en mémoire dans l'espace dédié, et choisissez dans ``local path`` le répertoire de votre machine dans lequel votre projet sera copié. Appuyez sur le bouton ``Clone`` de l'interface pour lancer l'importation de votre projet **gitlab** sur votre machine.    
+
+<center><img src="figures/ImportGithubDesktop.png" style="width:50%"/></center>
+
+- Observez alors la fenêtre qui apparaît. Elle vous permet     
+    - soit d'ouvrir les fichiers avec votre éditeur préféré (vous pouvez le configurer en suivant le lien ``Preferences``, puis menu ``Integrations``). Comme nous programmons avec ``Anaconda/Spyder``, cette possibilité ne sera pas utile.    
+    - soit d'ouvrir un gestionnaire de fichiers vous permettant de visualiser votre copie locale du projet. En navigant dans les sous-répertoires, vous verrez apparaître l'énoncé du BE (au format ``markdown``). 
+
+Les étapes décrites jusqu'ici ne doivent être faites qu'une seule fois par projet.
+
+----
+
+Vous pouvez maintenant modifier les fichiers de votre copie locale, ou en créer d'autres. Pour cela, vous pouvez utiliser ``Spyder``, ou tout autre éditeur de texte, à votre convenance! Pensez bien à sauvegarder vos scripts ``python`` dans le dossier du BE!
+
+À ce stade, seule votre copie locale est à jour, il faut ensuite penser à publier vos modifications sur votre espace **gitlab**. A minima, vous devrez le faire à chaque fin de séance de BE. 
+
+## 3. Mise à jour de votre espace gitlab
+
+La mise à jour de votre espace **gitlab** (au plus tard le dernier jour autorisé pour rendre votre travail) se fait en 2 étapes:
+
+ 1. Ouvrez à nouveau le logiciel ``GitHub Desktop``. L'application montre alors les différences, fichier par fichier,  qui existent entre la précédente version de vos fichiers et les changements que vous avez effectués depuis. Pour que **git** enregistre ces changements, veuillez taper un petit texte qui donne une explication sur vos modifications (typiquement: *réponse aux questions du BE 3*) dans la barre en bas à gauche, et appuyez sur le bouton ``Commit to master``.    
+<center><img src="figures/Commit.png" style="width:50%"/></center>   
+ 1. Pour mettre à jour ces changements sur votre espace **gitlab**, appuyez sur le bouton ``Push Origin``. Veuillez ensuite constater que les changements ont bien été publiés en consultant l'url de votre projet **gitlab** (faites un rafraîchissement de la page si nécessaire).
+
+En général, on réalise l'étape 1. très régulièrement (même si votre programme ne fonctionne pas). L'étape 2. est réalisée lorsque l'on a terminé  un algorithme par exemple ; on prend soin de publier des programmes qui fonctionnent, sans nécessairement qu'ils soient parfaits. Vous devrez réaliser *au minimum* les étapes 1. et 2. avant la date butoir pour le rendu de votre travail.
+
+Et voilà, le tour est joué ! 
+
+<!--
+Vous connaissez maintenant les étapes pour publier vos modifications. 
+
+La dernière étape décrite dans ce tuto concerne la mise à jour de votre ``fork`` lorsque les énoncés de BE changent ou lorsque de nouveaux énoncés sont publiés sur le projet original : https://gitlab.ec-lyon.fr/sderrode/INF-TC2.
+
+
+## 3. Mise à jour de votre espace **gitlab**
+
+Les énoncés des BE sont déposés sur l'espace https://gitlab.ec-lyon.fr/sderrode/INF-TC2 au fur et à mesure des semaines de BE. Et votre copie doit être mise à jour pour tenir compte de ces modifications.
+
+Pour que cela se fasse automatiquement, veuillez suivre les étapes suivante (à ne réaliser qu'une seule fois):
+ - Vous devez modifier les paramètres de votre fork. On accède aux paramètres en cliquant sur l'icône représentant la roue crantée (``Settings``), cherchez bien sur la page Web ! Allez ensuite dans le sous-menu ``Repository`` et sélectionnez le bouton ``Expand`` en face de ``Miroring repositories``. 
+  - Dans le champs correspondant à ``Git repository URL``, copiez le lien https://gitlab.ec-lyon.fr/sderrode/INF-TC2, ajoutez un mot de passe, et appuyer sur le bouton ``Miror repository``.
+
+Voilà le tour est joué ! Ainsi, dès qu'un changement apparaîtra sur le site d'origine, votre copie sur **gitlab** en tiendra compte. Mais pas votre copie locale sur votre machine! Avant de travaillez vos programmes (typiquement: en début de séance de BE), il faut donc penser à mettre à jour votre copie locale des fichiers. Pour cela, lancez  ``GitHub Desktop``. Si des changements nécessitent d'être importés, alors l'interface vous proposera de le faire. Bien sûr, cette étape fusionne les fichiers sans rien vous faire perdre de votre travail personnel.
+
+-->
+

tuto-git-gitlab/tuto-git-gitlab.md

+**Sommaire**
+
+[[TOC]]
+
+
+# Tuto sur git/gitlab
+
+Ce document présente un tuto à l'usage de _git_/_gitlab_. Il est consultable sous forme de [vidéo sur Moodle](https://pedagogie1.ec-lyon.fr/course/view.php?id=969).
+
+Comme tout tutoriel, ce document a besoin de vos retours pour s'améliorer! N’hésitez pas à m'envoyez un mail décrivant vos difficultés et, éventuellement, les solutions que vous auriez trouvées pour les contourner.
+
+
+> *Remarque* : Pour utiliser _git_, vous devez savoir ouvrir un _Terminal_ sur votre machine, quelque soit le système d'exploitation (_Windows_, _Linux_, ou _Mac OS X_). Sous _Windows X_, vous pourrez utiliser le programme _Windows powershell_ qui est très similaires au _Terminal_ de _Linux_ et de _Mac OS X_. Vous devez aussi savoir naviguer dans vos dossiers à l'aide de la commande ```cd```. Typiquement :
+```shell
+cd c:\Users\stephane\TP_Hadoop # Windows
+cd ~\TP_Hadoop                 # Mac, linux
+```
+Si vous souhaitez remonter d'un niveau dans la hiérarchie des dossiers: `cd ..`. Des tutos vidéo existent pour découvrir les commandes de bases (identiques à celles que l'on retrouve sur les systèmes _Linux_).
+
+
+---
+## Installer _git_ pour Windows (si requis) et *Github Desktop*
+
+Avant de commencer, il faut vérifier que _git_ (un gestionnaire de version de fichiers) est bien installé sur votre machine. _git_ est normalement disponible par défaut sur les machines *Mac OS X*, *Linux* et *Windows 10*. Pour vérifier, lancez la commande suivante dans un _Terminal_
+```shell
+git --version
+```
+Si _git_ est absent, alors installez-le grâce au lien suivant [git-scm](https://git-scm.com/download/win). Lors de l'installation, validez les choix par défaut qui vous sont proposés.
+
+L'interface *Github Desktop* que nous allons installer n'est absolument pas nécessaire pour travailler avec _git_. Mais elle évite, dans un premier temps, d'utiliser des commandes manuelles à partir d'un _Terminal_.
+
+ 1. Téléchargez, installez et lancez l'application [Github Desktop](https://desktop.github.com/).
+ <center><img src="figures/GithubDesktop_vierge.png" style="width:50%"/></center>
+ 1. Configurer *Github Desktop* (cette étape n'est nécessaire que si vous ne l'avez pas déjà fait lors de l'installation du logiciel) : aller dans le menu ``Préférences / git`` et entrez votre nom ainsi que votre adresse émail.
+
+
+---
+## Gérer son premier projet _git_ avec _gitlab_
+
+ 1. Montrer l'interface de _gitlab_    
+    - Adresse: https://gitlab.ec-lyon.fr;    
+    - Identifiant: ceux de l'ECL;     
+    - Naviguer dans le projet INF-TC2;
+ 1. Créer un nouveau projet    
+    - Nom : _HelloWorld_;     
+    - Description: Mon premier projet _gitlab_;    
+    - Discuter *Public/Internal/Private*;   
+    - Sélectionner *Initialize repository with a README*;
+    <center><img src="figures/Gitlab_newproject.png" style="width:50%"/></center>
+    - Cliquer sur l'icône `Clone` et copier le lien `Clone with HTTPS`, qui ressemble à `https://gitlab.ec-lyon.fr/xyyyyy/helloworld.git`. 
+ 1. Basculer sur *Github Desktop*,     
+    - Sélectionner l'option `Clone a Repository from the Internet`, puis l'onglet `URL` (ou menu `File > Clone repository`).
+    - Recopier l'adresse précédemment mise en mémoire dans l'espace dédié, et choisir dans `local path` le répertoire dans lequel votre projet sera copié. Appuyez sur le bouton `Clone` de l'interface pour lancer l'importation de votre projet _gitlab_ sur votre machine.
+    - Vérifier avec un gestionnaire de fichiers que le *repo* est bien copié localement sur sa machine et qu'il contient un répertoire caché (`.git`) ainsi que le fichier *readme.md*.   
+    - Basculer sur l'onglet `history`, et commenter.     
+ 1. Pour éviter que certains fichiers temporaires ne soient suivis par _git_, on va spécifier les fichiers a exclure dans un fichier appelé *.gitignore* (il s'agit d'un fichier caché). Pour cela    
+    - Aller dans le menu `Repository > Repository settings`, puis `Ignored Files`.   
+    - Copier le contenu du fichier qui se trouve à l'adresse `https://github.com/github/gitignore/blob/master/Python.gitignore dans l'espace réservé, puis `Save`.    
+    <center><img src="figures/gitignore.png" style="width:50%"/></center>      
+    - On doit alors *commiter* les changements (le texte par défaut qui décrit le `commit` est OK). Plus de détails sur ces `commits` plus loin.      
+ 1. Éditer le fichier *readme.md* avec *Sublime Text* (ou tout autre éditeur de texte) et enregistrer les changements localement:
+    - Basculer vers *Github Desktop* et discuter les changements qui interviennent sur l'interface.    
+    - *Commiter* les changements, et monter l'onglet *History*.    
+    - *Pusher* le travail vers _gitlab_ en utilisant l'option *Publish Branch*.
+    - Basculer vers _gitlab_ et vérifier que les changements ont bien étaient publiés   
+ 1. Basculer vers *Spyder* pour éditer du code _Python_:   
+    - Taper un programme *incremente_de_un(x)* et sauvegarder dans votre répertoire local sous le nom de fichier *incremente.py*. 
+    - *commiter* les changements dans *Github Desktop*   
+    - Refaire la même chose avec un autre fichier (*incremente_de_deux(x)*), à sauvegarder dans un sous répertoire *test*.
+    - *Pusher* son travail vers _gitlab_, et vérifier que tout se met bien à jour.
+
+
+De manière synthétique, une fois le projet créé,
+
+   1. vous modifiez vos code sources, et enregistrez régulièrement vos changements avec un `commit` (donc en local). Vous pouvez `commiter` des sources même s'ils ne sont pas terminés ou comportent des bugs. À ce stade cela n'a pas d'importance.     
+   1. quand vous êtes content de votre travail, et que vous jugez vos algorithmes fonctionnels, vous pouvez alors publier vos précédents `commit` sur _gitlab_ avec un `push`.
+
+Ce comportement est illustré par le schéma de la figure suivante:
+<center><img src="figures/PrincipeGit.png" style="width:50%"/></center>   
+
+-----
+Pour détruire ce projet (sans grand intérêt), il faut :
+
+ 1. Quitter Spyder pour fermer les fichiers en cours.
+ 1. Détruire la version locale en utilisant *Github Desktop*: sélectionner l'onglet `Current Repository`, et le menu contextuel sur le nom de votre projet permet d'accéder à `Remove`. Penser à cocher la suppression physique des fichiers si vous le souhaitez (sinon seul la gestion du projet par *Github Desktop* sera supprimée, les fichiers seront toujours présents sur votre disque dur).
+ 1. Détruire la version distante sur _gitlab_: Dans la barre de menu latérale à gauche de l'interface Web, sélectionnez l'icône représentant une roue crantée correspondant à `Settings`. Dans le sous-menu `Général`, appuyez sur le bouton `Expand` correspondant à la ligne : *Advanced*. Tout en bas, sélectionner `Delete Project`, copier la phrase demandée et appuyer sur le bouton pour confirmer.
+
+
+-----
+A quoi ça sert d'utiliser _git_ et _gitlab_ ? Les avantages sont nombreux:
+
+ - Avoir un copie de son travail sur un serveur distant.
+ - Sauvegarde incrémentale et disposer d'un historique des modifications (undo infini!)
+ - Partager son travail avec tout le monde (si votre projet est publique), ou avec des personnes choisies (invitations personnelles).
+ - Travailler à plusieurs sur le même projet et en même temps (mais ça, c'est un autre tuto...)   
+      - fusion automatique (ou presque) des sources,
+      - traçage des modification (qui, quoi).
+      - ...
+
+**Stéphane Derrode**
\ No newline at end of file