diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000000000000000000000000000000000000..ad6f92746914fa530f44f24b86e7b60c09f98c60
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,8 @@
+.Rproj.user
+.Rhistory
+.RData
+.Ruserdata
+intro_git.Rproj
+Intro_git_gitlab_with_rstudio.html
+index.html
+public
\ No newline at end of file
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 04ca17201e2337111fa78da3affd3383a4c7696d..098e053a393c55ae133257c7b8739bd5a78873c0 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -3,9 +3,10 @@
pages:
stage: deploy
- image: rocker/r-rmd
+ image: registry.gitlab.com/quarto-forge/docker/polyglot
script:
- make
+ interruptible: true
artifacts:
paths:
- public
diff --git a/Intro_git_gitlab_with_rstudio.qmd b/Intro_git_gitlab_with_rstudio.qmd
new file mode 100644
index 0000000000000000000000000000000000000000..41049e6d924bbdf1d53b66905763140adfc970fe
--- /dev/null
+++ b/Intro_git_gitlab_with_rstudio.qmd
@@ -0,0 +1,352 @@
+---
+title: "USEFUL INFORMATION: Short introduction to script versionning (git) through Rstudio"
+subtitle: "UE NGS - ENS LYON"
+author: "NGS-team - 2023"
+
+title-block-banner: true
+format: html
+toc: true
+toc-title: Contents
+theme: united
+number-sections: true
+embed-resources: true
+anchor-sections: true
+---
+
+
+
+Cette intro est une compilation de différents tutoriels disponible sur le web:
+
+* https://www.miximum.fr/blog/enfin-comprendre-git/
+* https://www.git-tower.com/learn/git/ebook/en/command-line/
+* https://linogaliana.gitlab.io/collaboratif/git.html
+* https://www.book.utilitr.org/git.html
+* https://thinkr.fr/travailler-avec-git-via-rstudio-et-versionner-son-code/
+* https://www.bioinformatics.babraham.ac.uk/training/RStudio_GitHub/Initial_setup.html
+
+Le but est d'acquérir les concepts et les commandes de bases pour que vous soyez autonome dans :
+
+ * votre utilisation de git via rstudio et de votre dépot gitlab
+ * la recherche de fonctionnalités de git
+ * **et surtout** la résolution de vos problèmes avec git (car oui, vous en aurez!)
+
+# Pourquoi utiliser Git ?
+
+## Sans git
+
+ * Gestion des fichiers chaotiques entre
+ * les différentes versions d'un fichier (V1,V2,final, final_ok ....)
+ * les différents backups du système (PC, Disques de sauvegarde, ...)
+ * les différents utilisateurs ...
+ * Aucune trace du pourquoi des modifications
+
+Cette BD doit parler à tout le monde :
+
+<img src="http://phdcomics.com/comics/archive/phd101212s.gif" alt="" width="400"/>
+
+## Avec git
+
+ * Conservation et archivage de votre projet
+ * Historique clair des modifications
+ * Travail collaboratif efficace:
+
+ * Travailler en parallèle et fusionner facilement des fichiers
+ * Garder l'historique de qui a fait quoi
+
+# Git une machine à voyager dans le temps
+
+Git vous permet d’écrire l’histoire de votre projet, seul ou à plusieurs, via des snapshots, que l’on peut voir comme des instantanés ou photographies du dossier et des fichiers contenus que vous souhaitez suivre. Ce dossier est le *repository*. À chaque fois que l’on souhaite figer l’état du *repository*, prendre une photo, on fait ce que l’on appelle un *commit*.
+
+Chaque *commit* enregistre un certain nombre d’informations :
+
+ * qui a fait la modification
+ * quand la modification a été réalisée
+ * pourquoi la modification a été réalisée, description de la modification (via un message de *commit*)
+
+Au fil des *commits* vous aller construire un *historique* qui sera consultable. L'histoire principale qui contient la version "propre" de votre *repository* se situe sur la branche appellée *master*.
+
+Vous pourrez également créer à partir d'un *commit* des *branches* parallèles. Par exemple, vous pourrez créer une branche supplémentaire afin de faire quelque chose "juste pour voir" et abandonner votre idée ou bien, conserver vos modifications et les fusionner à la branche *master* via un *merge*. Mais dans les deux cas, vous en aurez gardé une trace.
+
+<img src="figures/git-branches-merge.png" alt="" width="400"/>
+
+ Dans le TP, nous n'utiliserons pas de branches supplémentaires mais sachez qu'elles existent et qu'elles rendent cet outil, git, si puissant et indispensable pour des projets collaboratifs.
+
+## Collaborer ou archiver votre code via un dépot distant (ex: gitlab/github)
+
+Git vous permet de faire un backup de votre projet versionné. Sur un serveur distant, ailleurs, on appelle cet endroit le *remote*. Votre *remote* peut être sur Github (le plus célèbre) ou sur un Gitlab auto-hébergé (Comme ici à l'ENS).
+
+Pour récupérer un projet depuis un *remote*, la première fois, on effectue un *clone* ; comme son nom l’indique, on *clone* le projet, on en fait une copie que l’on récupère en local, sur notre machine. Lorsqu’on fait des *commit* sur son projet local, on va pouvoir les envoyer sur le *remote* en faisant un *push*. Les autre personnes connectées au *remote* effectueront un *pull* pour récupérer vos *commit*.
+
+De cette manière, la version locale (sur votre ordinateur) et la version distante (sur le *remote*) de votre projet sont toujours synchronisées.
+
+## Comment écrire votre histoire ?
+
+Les trois manipulations les plus courantes sont les suivantes et représentées sur le schéma ci-après :
+
+ * *pull* : je récupère la dernière version des fichiers du dépôt distant
+ * *commit* : je valide mes modifications avec un message qui les expliquent
+ * *push* : je transmets mes modifications validées au dépôt distant
+
+<img src="figures/push_pull_Drees.png" alt="" width="400"/>
+
+
+De manière plus exacte, il existe une étape supplémentaire à faire avant de valider vos modifications (cad de faire un *commit*), c'est l'indexation de vos modifications.
+En effet, git vous permet de gérer de manières subtiles les modifications et ne pas prendre en compte toutes les modifications de votre espace de travail (*working directory*).
+Seules les modifications indexées, celles que vous aurez ajoutées à votre *staging area* via la commande *stage* seront enregistrées dans votre *commit*.
+
+Pour résumer :
+
+1 - Tout d'abord vous faites les modifications dans vos fichiers mais ces changements ne seront pas enregistrés dans le dépot.
+
+<img src="figures/git-stages0.png" alt="" width="400"/>
+
+2 - Par la commande *stage*, vous allez sélectionner les modifications que vous alllez inclure dans le prochain *commit* et les placer dans la *staging area*.
+
+<img src="figures/git-stages1.png" alt="" width="400"/>
+
+3 - Puis avec la commande *commit*, vous enregistrez les modifications sélectionnées via le *stage* dans la *staging area*.
+
+<img src="figures/git-stages2.png" alt="" width="400"/>
+
+Ces différentes étapes peuvent être exécuté via la ligne de commande mais il existe des outils graphiques pour le faire ou bien la majorité des éditeurs (IDE) tel que Rstudio ou Visual Code ont des plugins pour vous faciliter la vie.
+
+<img src="figures/git-stages.png" alt="" width="400"/>
+
+
+## Récapitulatif des commandes clés à connaitre :
+
+- clone : récupérer pour la première fois le *repository* depuis le *remote*
+- stage : enregistrer les modifications qui seront ajoutées au prochian *commit*
+- commit : un instant figé dans la vie de votre projet
+- push : envoyer ses nouveaux *commit* vers le *remote*
+- pull : récupérer les nouveaux *commit* en local depuis le *remote*
+- checkout : un saut dans le temps vers un *commit*
+
+Vous pourez avoir une vision plus globale de votre environement avec ce schéma :
+
+<img src="figures/basic-remote-workflow.png" alt="" width="400"/>
+
+Maintenant que nous avons vu les grands principes, à vous d'essayer !
+
+# A vous de jouer: Initialisation de votre projet Git sur le Gitlab et utilisation de Rstudio pour le gérer en local
+
+## Lier Gitlab et votre machine en utilisant Rsudio
+
+### 1. Créer un compte sur le [Gitlab du labo](https://gitbio.ens-lyon.fr/): https://gitbio.ens-lyon.fr/
+
+Si vous n'avez pas encore de compte:
+
+ - Aller sur le site et essayer de vous connecter via **SSO Ens de Lyon**, celà va vous redirigérer vers le CAS afin de vos connecter avec vos identifiants ENS.
+ - Vous serez alors bloquer c'est normal. Carine va recevoir une demande de compte et pourra la valider
+ - Envoyer un mail à Carine (carine.rey@ens-lyon.fr) en précisant le nom de votre groupe.
+
+
+
+### Créer un nouveau *repository* sur le [Gitlab du labo](https://gitbio.ens-lyon.fr/)
+
+- Cliquer sur le groupe de l'UE (Menu -> groups -> your groups) (https://gitbio.ens-lyon.fr/ue/ue-ngs/students_2023)
+
+- Puis créer un projet en cliquant sur (**Create new project**)
+ - Selectionner créer depuis un projet vide (**Create blank project**)
+ - Donner un nom à votre projet contenant le nom de votre groupe et votre nom (Le nom de votre projet doit être idéalement en minuscule, sans point, espace ou underscore, et ne doit pas commencer par un chiffre, ex: scRNAseq_arabido_carine)
+ - **Laisser selectionné** *Initialize repository with a README*
+ - Cliquer sur **Create project**
+
+
+### Création de votre paire de clés ssh
+
+
+Nous devons permettre à Rstudio de pouvoir se connecter à gitlab, pour celà nous allons utiliser une paire de clés ssh qui est plus sécurisé qu'un login/mot de passe.
+
+Si vous avez déjà une paire de clés ssh, il est quand même préférable de refaire une paire de fichiers spécifiques pour la connexion au gitlab.
+
+Nous allons utiliser Rstudio pour générer cette paire de clés (qui sont en fait simplement 2 fichiers, l'un appelé "**clé privée**" et le second "**clé publique**").
+La clé privée peut être symbolisée par une clé de cadenas et la clé publique par la serrure de ce cadenas.
+
+
+Nous allons créer directement ces deux fichiers via Rstudio sur votre machine virtuelle.
+
+Dans Rstudio:
+
+1- cliquer sur "Tools > Global Options…> Git/SVN"
+
+2- cliquer sur "Create ssh Key ..."
+
+3- une fenêtre va s'ouvir, rentrez une passphrase (=un mot de passe qui va sécuriser l'utilisation de votre clé privée) et valider
+
+<img src="figures/create_ssh_key_from_rstudio.png" alt="" width="400"/>
+
+4- Puis cliquer sur "Close"
+
+5 - Acceder à la clé public (=contenu du fichier id_ed25519.pub) en cliquant sur "View public key"
+
+<img src="figures/create_ssh_key_from_rstudio_get_public_key_fleche.png" alt="" width="400"/>
+
+6- Copier votre clé public
+
+<img src="figures/create_ssh_key_from_rstudio_copy_public_key.png" alt="" width="400"/>
+
+7- Dans votre profil sur Gitlab, en haut à gauche, cliquer sur votre avatar puis sur **Preferences** puis **ssh keys** (dans le panneau à gauche). Vous devriez arriver sur cette page : <https://gitbio.ens-lyon.fr/-/profile/keys>
+
+<img src="figures/preference_ssh_key_gitbio.png" alt="" width="600"/>
+
+8- Ajouter votre nouvelle clé
+
+
+*On pourrait également créer ces fichiers en ligne de commandes via le terminal. Vous pouvez trouvez de l'aide dans la documentation de gitlab ou bien sur internet si vous devez le refaire (ex: https://happygitwithr.com/ssh-keys.html#create-an-ssh-key-pair).*
+
+Pour vérifiez que tout est bon vous pouvez taper dans le terminal (via rstudio) :
+
+```
+ssh -T git@gitbio.ens-lyon.fr
+```
+
+<img src="figures/test_ssh_keys.png" alt="" width="600"/>
+
+- Répondez "yes" à la question
+- Renseignez votre passphrase (elle ne s'affichera pas, c'est normal.)
+
+Vous devriez avoir comme réponse :
+```
+Welcome to GitLab, @votre_login!
+```
+<img src="figures/create_ssh_key_from_rstudio_check_key.png" alt="" width="400"/>
+
+### Configurer git dans Rstudio
+
+Enfin, il faudra déclarer votre identité : dans le terminal de RStudio (attention pas la console R), tapez en renseignant votre nom afin que chacun de vos *commit* vous soit rattaché :
+
+```
+git config --global user.name "your_pseudo"
+git config --global user.email "your_mail@mail.com"
+```
+
+<img src="figures/config_git_rstudio.png" alt="" width="400"/>
+
+
+### Cloner votre dépot vide et créer un projet R dans Rstudio
+
+
+Pour associer ce *repository* Git à un projet R via RStudio, vous devez faire un clone :
+
+ * Sur Gitlab: cliquez sur Code et copiez l’URL (protocole SSH)
+
+<img src="figures/git_clone_gitlab.png" alt="" width="400"/>
+
+
+ * Dans RStudio maintenant : File > New Project… > Version Control > Git, renseignez l’URL/le SSH de votre repository que vous avez préalablement copié, le nom du projet R (le même que Git idéalement) et le dossier dans lequel le placer **(~/mydatalocal)**, cliquez sur Create Project et enfin renseignez votre passphrase.
+
+<img src="figures/git_rstudio_newproj_gitlab.png" alt="" width="400"/>
+
+
+ Dans ce nouveau projet RStudio créé, vous verrez apparaître l’onglet git en haut à droite.
+
+ <img src="figures/git_rstudio_gittab.png" alt="" width="400"/>
+
+
+## Utilsation des commandes git dans Rstudio
+
+Le panneau Git de RStudio vous indique en temps réel l’état de votre projet : le statut des différents fichiers et dossiers sera affiché :
+
+ <img src="figures/git_etat_fichier.png" alt="" width="400"/>
+
+ * Un nouveau fichier sera associé à une icone orange contenant un ?
+ * Ce nouveau fichier sera associé à une icone verte contenant un A une fois que vous l’aurez coché (dans la colonne ‘staged’)
+ * Un fichier modifié sera associé à une icone bleue contenant un M
+ * Un fichier effacé sera associé à une icone rouge contenant un D
+
+## Configurer les fichiers à suivre ou ne pas suivre : le .gitignore
+
+Il est n’est pas nécessaire de versionner l’intégralité des fichiers de votre projet. Seuls ceux que vous cocherez seront associés à des commits. En ce sens, il est possible de demander explicitement à Git de ne pas surveiller tel ou tel fichier : c’est le rôle du fichier *.gitignore* qui se trouve à la racine de votre projet. Il s’agit d’un fichier texte qui accepte les expressions régulieres et permet de définir des régles qui correspondent à plusieurs fichiers :
+
+ <img src="figures/git_gitignore.png" alt="" width="400"/>
+
+Par defaut, en créant le projet Rstudio, un fichier .gitignore est ajouté contenant les lignes suivantes:
+
+```
+.Rproj.user
+.Rhistory
+.RData
+.Ruserdata
+```
+
+Cela permet de ne pas suivre les fichiers de configuration du projet Rstudio.
+
+Pour le TP et en général nous ne voulons pas également suivre les modifications liées aux données brutes, ni aux résultats.
+
+1. Ajouter au fichier *.gitignore* les lignes suivantes :
+
+```
+data/
+results/
+*.Rproj
+```
+
+2. Indexer les modifications en cliquant dans la colonne *staged* la case en face du fichier *.gitignore*.
+
+3. Puis faire un commit en mettant un message explicite.
+
+4. Puis *pusher* les modifications pour synchroniser vos modifications locales avec le *remote*.
+
+5. Visionner les changements sur gitlab
+
+
+## Organiser votre dossier de travail
+
+
+Il est conseillé de mettre dans un même dossier tous les fichiers liés à un même projet, que ce soient :
+
+ * les données brutes,
+ * les scripts,
+ * les résutats intermédiaires,
+ * les résultats,
+ * la documentation du projet,
+ * ...
+
+Afin de s'y retrouver et de ne pas mélanger les fichiers ou d'accidentellement supprimer des fichiers, il est recommandé de séparer les différents types de données dans des sous-dossiers.
+
+Par exemple, votre dossier de travail pourra ressembler à ça :
+
+```
+project_name/
+├── README.md # overview of the project
+├── data/ # data files used in the project
+├── results/ # results of the analysis (data, tables, figures)
+├── src/ # contains all code in the project
+│ └── ...
+└── doc/ # documentation for your project
+ └── ...
+```
+
+De plus, pour s'y retrouver et pour des questions de reproductibilité, il faut ajouter un fichier, souvent nommé **README.md**, à la racine de votre dossier qui va contenir toutes les informations utiles pour prendre en main le projet.
+
+Il s'agit également du fichier qui sera visible sur la page d'accueil de votre projet sur gitlab.
+Ainsi lorsque qu'une personne voudra (re)travailler sur le projet, elle pourra ouvrir le dossier, et elle sera où se diriger pour voir et comprendre ce qu'il a été fait.
+Cette personne peut être un collaborateur, votre responsable ou bien simplement vous-même 6 mois plus tard.
+
+### Le README.md
+
+Concrètement, le fichier README.md est un fichier texte écrit en markdown (d'où l'extention .md).
+Le markdown est un language qui permet de coder le formatage d'un texte brute simplement.
+
+Par exemple un # signifie que la phrase suivante est un titre, ## , un sous titre, ###, un sous sous titre.
+Vous pouvez parcourir les différentes balises existantes ici : [https://www.markdownguide.org/basic-syntax/](https://www.markdownguide.org/basic-syntax/)
+
+Cela permet donc d'écrire du texte sans perdre de temps avec le formatage, conserver un fichier "léger" et surtout lisible pour tous.
+Sur la page Gitlab de votre projet, vous retrouverer votre fichier **README.md** mis en forme.
+
+N'oubliez pas de compléter votre README.md au fur et à mesure du TP afin de ne rien oublier.
+Il peut également être représenté comme votre cahier de laboratoire ou bien votre rapport de TP.
+
+A la fin du TP, la qualité de votre README.md sera particulièrement pris en compte lors de l'évaluation.
+
+### Créer l'architecture de votre projet
+
+1. Créer votre README.md
+2. Commencer à le compléter
+2. Indexer, commiter, pusher ...
+3. Créer les dossiers data, results, scripts
+4. Indexer, commiter, pusher ...
+3. Mettre à jour le fichier .gitignore
+4. Indexer, commiter, pusher ...
+
diff --git a/Makefile b/Makefile
index 49444b329ed9f324910a219701161a2d488c70a7..b7162d3803b77da0d8b1bb424b0ca525bc7451e1 100644
--- a/Makefile
+++ b/Makefile
@@ -3,7 +3,6 @@ all: public/index.html
public/:
mkdir -p public
-public/index.html: public/ README.md
- pandoc -s -c www/github-pandoc.css README.md -o public/index.html
-
-.PHONY: make_pdf
\ No newline at end of file
+public/index.html: public/ Intro_git_gitlab_with_rstudio.qmd
+ quarto render Intro_git_gitlab_with_rstudio.qmd
+ mv Intro_git_gitlab_with_rstudio.html public/index.html
\ No newline at end of file
diff --git a/README.md b/README.md
index 1410580faf0b71bcfe81cdd987cd63e35d2373f1..858cfd5a0e3ba5eed2c8b3e28269a3d4a12b8408 100644
--- a/README.md
+++ b/README.md
@@ -1,326 +1,4 @@
-# **Courte introduction à** 
-
-Cette intro est une compilation de différents tutoriels disponible sur le web:
-
-* https://www.miximum.fr/blog/enfin-comprendre-git/
-* https://www.git-tower.com/learn/git/ebook/en/command-line/
-* https://linogaliana.gitlab.io/collaboratif/git.html
-* https://www.book.utilitr.org/git.html
-* https://thinkr.fr/travailler-avec-git-via-rstudio-et-versionner-son-code/
-
-Le but est d'acquérir les concepts et les commandes de bases pour que vous soyez autonome dans :
-
- * votre utilisation de git via rstudio et de votre dépot github
- * la recherche de fonctionnalités de git
- * **et surtout** la résolution de vos problèmes avec git (car oui, vous en aurez!)
-
-## Pourquoi utiliser Git ?
-
-### Sans git
-
- * Gestion des fichiers chaotiques entre
- * les différentes versions d'un fichier (V1,V2,final, final_ok ....)
- * les différents backups du système (PC, Disques de sauvegarde, ...)
- * les différents utilisateurs ...
- * Aucune trace du pourquoi des modifications
-
-Cette BD doit parler à tout le monde :
-
-<img src="http://phdcomics.com/comics/archive/phd101212s.gif" alt="" width="400"/>
-
-### Avec git
-
- * Conservation et archivage de votre projet
- * Historique clair des modifications
- * Travail collaboratif efficace
- * Travailler en parallèle et fusionner facilement des fichiers
- * Garder l'historique de qui a fait quoi
-
-## Git une machine à voyager dans le temps
-
-Git vous permet d’écrire l’histoire de votre projet, seul ou à plusieurs, via des snapshots, que l’on peut voir comme des instantanés ou photographies du dossier et des fichiers contenus que vous souhaitez suivre. Ce dossier est le *repository*. À chaque fois que l’on souhaite figer l’état du *repository*, prendre une photo, on fait ce que l’on appelle un *commit*.
-
-Chaque *commit* enregistre un certain nombre d’informations :
-
- * qui a fait la modification
- * quand la modification a été réalisée
- * pourquoi la modification a été réalisée, description de la modification (via un message de *commit*)
-
-Au fil des *commits* vous aller construire un *historique* qui sera consultable. L'histoire principale qui contient la version "propre" de votre *repository* se situe sur la branche appellée *master*.
-
-Vous pourrez également créer à partir d'un *commit* des *branches* parallèles. Par exemple, vous pourrez créer une branche supplémentaire afin de faire quelque chose "juste pour voir" et abandonner votre idée ou bien, conserver vos modifications et les fusionner à la branche *master* via un *merge*. Mais dans les deux cas, vous en aurez gardé une trace.
-
-<img src="figures/git-branches-merge.png" alt="" width="400"/>
-
- Dans le TP, nous n'utiliserons pas de branches supplémentaires mais sachez qu'elles existent et qu'elles rendent cet outil, git, si puissant et indispensable pour des projets collaboratifs.
-
-### Collaborer ou archiver votre code via un dépot distant (ex: gitlab/github)
-
-Git vous permet de faire un backup de votre projet versionné. Sur un serveur distant, ailleurs, on appelle cet endroit le *remote*. Votre *remote* peut être sur Github (le plus célèbre) ou sur un Gitlab auto-hébergé (Comme ici à l'ENS).
-
-Pour récupérer un projet depuis un *remote*, la première fois, on effectue un *clone* ; comme son nom l’indique, on *clone* le projet, on en fait une copie que l’on récupère en local, sur notre machine. Lorsqu’on fait des *commit* sur son projet local, on va pouvoir les envoyer sur le *remote* en faisant un *push*. Les autre personnes connectées au *remote* effectueront un *pull* pour récupérer vos *commit*.
-
-De cette manière, la version locale (sur votre ordinateur) et la version distante (sur le *remote*) de votre projet sont toujours synchronisées.
-
-### Comment écrire votre histoire ?
-
-Les trois manipulations les plus courantes sont les suivantes et représentées sur le schéma ci-après :
-
- * *pull* : je récupère la dernière version des fichiers du dépôt distant
- * *commit* : je valide mes modifications avec un message qui les expliquent
- * *push* : je transmets mes modifications validées au dépôt distant
-
-<img src="figures/push_pull_Drees.png" alt="" width="400"/>
-
-
-De manière plus exacte, il existe une étape supplémentaire à faire avant de valider vos modifications (cad de faire un *commit*), c'est l'indexation de vos modifications.
-En effet, git vous permet de gérer de manières subtiles les modifications et ne pas prendre en compte toutes les modifications de votre espace de travail (*working directory*).
-Seules les modifications indexées, celles que vous aurez ajoutées à votre *staging area* via la commande *add* seront enregistrées dans votre *commit*.
-
-Pour résumer :
-
-1 - Tout d'abord vous faites les modifications dans vos fichiers mais ces changements ne seront pas enregistrés dans le dépot.
-
-<img src="figures/git-stages0.png" alt="" width="400"/>
-
-2 - Par la commande *add*, vous allez sélectionner les modifications que vous alllez inclure dans le prochain *commit* et les placer dans la *staging area*.
-
-<img src="figures/git-stages1.png" alt="" width="400"/>
-
-3 - Puis avec la commande *commit*, vous enregistrez les modifications sélectionnées via le *add* dans la *staging area*.
-
-<img src="figures/git-stages2.png" alt="" width="400"/>
-
-Ces différentes étapes peuvent être exécuté via la ligne de commande mais il existe des outils graphiques pour le faire ou bien la majorité des éditeurs (IDE) tel que Rstudio ou Visual Code ont des plugins pour vous faciliter la vie.
-
-<img src="figures/git-stages.png" alt="" width="400"/>
-
-
-### Récapitulatif des commandes clés à connaitre :
-
-- clone : récupérer pour la première fois le *repository* depuis le *remote*
-- add : enregistrer les modifications qui seront ajoutées au prochian *commit*
-- commit : un instant figé dans la vie de votre projet
-- push : envoyer ses nouveaux *commit* vers le *remote*
-- pull : récupérer les nouveaux *commit* en local depuis le *remote*
-- checkout : un saut dans le temps vers un *commit*
-
-Vous pourez avoir une vision plus globale de votre environement avec ce schéma :
-
-<img src="figures/basic-remote-workflow.png" alt="" width="400"/>
-
-Maintenant que nous avons vu les grands principes, à vous d'essayer !
-
-## A vous de jouer: Initialisation de votre projet Git sur le Gitlab et utilisation de Rstudio pour le gérer en local
-
-### Lier Gitlab et votre machine en utilisant Rsudio
-
-#### 1. Créer un compte sur le [Gitlab du labo](https://gitbio.ens-lyon.fr/): https://gitbio.ens-lyon.fr/
-
-Si vous n'avez pas encore de compte:
-
- - Aller sur le site et essayer de vous connecter via le CAS, Carine va recevoir une demande de compte et pourra la valider
- - Envoyer un mail à Carine (carine.rey@ens-lyon.fr) en précisant le nom de votre groupe.
-
-#### 2. Créer un nouveau *repository* sur le [Gitlab du labo](https://gitbio.ens-lyon.fr/)
-
-- Cliquer sur le groupe de l'UE (Menu -> groups -> your groups) (https://gitbio.ens-lyon.fr/ue/ue-ngs/students_2022)
-
-- Puis créer un projet (**New project**)
- - Selectionner créer depuis un projet vide
- - Donner un nom à votre projet contenant le nom de votre groupe et votre nom (Le nom de votre projet doit être idéalement en minuscule, sans point, espace ou underscore, et ne doit pas commencer par un chiffre, ex: scRNAseq_arabido_carine)
- - **Laisser selectionné** *Initialize repository with a README*
- - Cliquer sur **Create project**
-
-
-#### 3. Création de votre paire de clés ssh
-
-Attention il s'agit d'une opération délicate, ne pas hésiter à demander de l'aide.
-
-Si vous avez déjà une paire de clés ssh, il est quand même préférable de refaire une paire de fichiers spécifiques pour la connexion au gitlab.
-
-Nous allons utiliser Rstudio pour générer cette paire de clés (qui sont en fait simplement 2 fichiers). On pourrait également le faire en ligne de commandes via le terminal. Vous pouvez trouvez de l'aide dans la documentation de gitlab ou bien sur internet si vous devez le refaire (ex: https://happygitwithr.com/ssh-keys.html#create-an-ssh-key-pair).
-
-Dans Rstudio:
-
-1- cliquer sur "Tools > Global Options…> Git/SVN"
-
-2- cliquer sur "Create ssh Key ..."
-
-3- une fenêtre va s'ouvir, rentrez une passphrase et valider
-
-<img src="figures/create_ssh_key_from_rstudio.png" alt="" width="400"/>
-
-4- Puis cliquer sur "Close"
-
-5 - Acceder à la clé public (=contenu du fichier id_ed25519.pub) en cliquant sur "View public key"
-
-<img src="figures/create_ssh_key_from_rstudio_get_public_key_fleche.png" alt="" width="400"/>
-
-6- Copier votre clé public
-
-<img src="figures/create_ssh_key_from_rstudio_copy_public_key.png" alt="" width="400"/>
-
-7- Dans votre profil sur Gitlab, en haut à doite, cliquer sur votre avatar puis sur **Preferences** puis **ssh keys** (dans le panneau à gauche). Vous devriez arriver sur cette page : https://gitbio.ens-lyon.fr/-/profile/keys
-
-8- Ajouter votre nouvelle clé
-
-<img src="figures/create_ssh_key_from_rstudio_add_public_key.png
-" alt="" width="400"/>
-
-
-La partie la plus compliquée est terminé.
-
-
-Pour vérifiez que tout est bon vous pouvez taper dans un terminal (via rstudio) :
-
-```
-ssh -T git@gitbio.ens-lyon.fr
-```
-
-- Répondez "yes" à la question
-- Renseignez votre passphrase
-
-Vous devriez avoir comme réponse :
-```
-Welcome to GitLab, @votre_login!
-```
-<img src="figures/create_ssh_key_from_rstudio_check_key.png" alt="" width="400"/>
-
-#### 4. Configurer git dans Rstudio
-
-Enfin, il faudra déclarer votre identité : dans le terminal de RStudio (attention pas la console R), tapez en renseignant votre nom afin que chacun de vos *commit* vous soit rattaché :
-
-```
-git config --global user.name "your_pseudo"
-git config --global user.email "your_mail@mail.com"
-```
-
-<img src="figures/config_git_rstudio.png" alt="" width="400"/>
-
-
-#### 5. Cloner votre dépot vide et créer un projet R dans Rstudio
-
-
-Pour associer ce *repository* Git à un projet R via RStudio, vous devez faire un clone :
-
- * Sur Gitlab: cliquez sur Code et copiez l’URL (protocole SSH)
-
-<img src="figures/git_clone_gitlab.png" alt="" width="400"/>
-
-
- * Dans RStudio maintenant : File > New Project… > Version Control > Git, renseignez l’URL/le SSH de votre repository que vous avez préalablement copié, le nom du projet R (le même que Git idéalement) et le dossier dans lequel le placer **(~/mydatalocal)**, cliquez sur Create Project et enfin renseignez votre passphrase.
-
-<img src="figures/git_rstudio_newproj_gitlab.png" alt="" width="400"/>
-
-
- Dans ce nouveau projet RStudio créé, vous verrez apparaître l’onglet git en haut à droite.
-
- <img src="figures/git_rstudio_gittab.png" alt="" width="400"/>
-
-
-### Utilsation des commandes git dans Rstudio
-
-Le panneau Git de RStudio vous indique en temps réel l’état de votre projet : le statut des différents fichiers et dossiers sera affiché :
-
- <img src="figures/git_etat_fichier.png" alt="" width="400"/>
-
- * Un nouveau fichier sera associé à une icone orange contenant un ?
- * Ce nouveau fichier sera associé à une icone verte contenant un A une fois que vous l’aurez coché (dans la colonne ‘staged’)
- * Un fichier modifié sera associé à une icone bleue contenant un M
- * Un fichier effacé sera associé à une icone rouge contenant un D
-
-### Configurer les fichiers à suivre ou ne pas suivre : le .gitignore
-
-Il est n’est pas nécessaire de versionner l’intégralité des fichiers de votre projet. Seuls ceux que vous cocherez seront associés à des commits. En ce sens, il est possible de demander explicitement à Git de ne pas surveiller tel ou tel fichier : c’est le rôle du fichier *.gitignore* qui se trouve à la racine de votre projet. Il s’agit d’un fichier texte qui accepte les expressions régulieres et permet de définir des régles qui correspondent à plusieurs fichiers :
-
- <img src="figures/git_gitignore.png" alt="" width="400"/>
-
-Par defaut, en créant le projet Rstudio, un fichier .gitignore est ajouté contenant les lignes suivantes:
-
-```
-.Rproj.user
-.Rhistory
-.RData
-.Ruserdata
-```
-Cela permet de ne pas suivre les fichiers de configuration du projet Rstudio.
-
-Pour le TP et en général nous ne voulons pas également suivre les modifications liées aux données brutes, ni aux résultats.
-
-1. Ajouter au fichier *.gitignore* les lignes suivantes :
-
-```
-data/
-results/
-*.Rproj
-```
-
-2. Indexer les modifications en cliquant dans la colonne *staged* la case en face du fichier *.gitignore*.
-
-3. Puis faire un commit en mettant un message explicite.
-
-4. Puis *pusher* les modifications pour synchroniser vos modifications locales avec le *remote*.
-
-5. Visionner les changements sur gitlab
-
-
-### Organiser votre dossier de travail
-
-
-Il est conseillé de mettre dans un même dossier tous les fichiers liés à un même projet, que ce soient :
-
- * les données brutes,
- * les scripts,
- * les résutats intermédiaires,
- * les résultats,
- * la documentation du projet,
- * ...
-
-Afin de s'y retrouver et de ne pas mélanger les fichiers ou d'accidentellement supprimer des fichiers, il est recommandé de séparer les différents types de données dans des sous-dossiers.
-
-Par exemple, votre dossier de travail pourra ressembler à ça :
-
-```
-project_name/
-├── README.md # overview of the project
-├── data/ # data files used in the project
-├── processed_data/ # intermediate files from the analysis
-├── results/ # results of the analysis (data, tables, figures)
-├── src/ # contains all code in the project
-│ └── ...
-└── doc/ # documentation for your project
- └── ...
-```
-
-De plus, pour s'y retrouver et pour des questions de reproductibilité, il faut ajouter un fichier, souvent nommé **README.md**, à la racine de votre dossier qui va contenir toutes les informations utiles pour prendre en main le projet.
-Il s'agit également du fichier qui sera visible sur la page d'accueil de votre projet sur gitlab.
-Ainsi lorsque qu'une personne voudra (re)travailler sur le projet, elle pourra ouvrir le dossier, et elle sera où se diriger pour voir et comprendre ce qu'il a été fait.
-Cette personne peut être un collaborateur, votre responsable ou bien simplement vous-même 6 mois plus tard.
-
-#### Le README.md
-
-Concrètement, le fichier README.md est un fichier texte écrit en markdown (d'où l'extention .md).
-Le markdown est un language qui permet de coder le formatage d'un texte brute simplement.
-
-Par exemple un # signifie que la phrase suivante est un titre, ## , un sous titre, ###, un sous sous titre.
-Vous pouvez parcourir les différentes balises existantes ici : [https://www.markdownguide.org/basic-syntax/](https://www.markdownguide.org/basic-syntax/)
-
-Cela permet donc d'écrire du texte sans perdre de temps avec le formatage, conserver un fichier "léger" et surtout lisible pour tous.
-Sur la page Gitlab de votre projet, vous retrouverer votre fichier **README.md** mis en forme.
-
-N'oubliez pas de compléter votre README.md au fur et à mesure du TP afin de ne rien oublier.
-Il peut également être représenté comme votre cahier de laboratoire ou bien votre rapport de TP.
-
-A la fin du TP, la qualité de votre README.md sera particulièrement pris en compte lors de l'évaluation.
-
-#### Créer l'architecture de votre projet
-
-1. Créer votre README.md
-2. Commencer à le compléter
-2. Indexer, commiter, pusher ...
-3. Créer les dossiers data, results, scripts
-4. Indexer, commiter, pusher ...
-3. Mettre à jour le fichier .gitignore
-4. Indexer, commiter, pusher ...
+# UE NGS: Using script versionning (git) through Rstudio
+USEFUL INFORMATION UE NGS - ENS LYON
+https://ue.gitbiopages.ens-lyon.fr/ue-ngs/presentations/intro_git/
\ No newline at end of file
diff --git a/figures/connexion_gitbio_SSO.png b/figures/connexion_gitbio_SSO.png
new file mode 100644
index 0000000000000000000000000000000000000000..df575b842b60990b5c3653f7e46ae3501911c76d
Binary files /dev/null and b/figures/connexion_gitbio_SSO.png differ
diff --git a/figures/connexion_gitbio_SSO_ok.png b/figures/connexion_gitbio_SSO_ok.png
new file mode 100644
index 0000000000000000000000000000000000000000..9aff167361453e0b4794e36d681095f85edeadb9
Binary files /dev/null and b/figures/connexion_gitbio_SSO_ok.png differ
diff --git a/figures/preference_ssh_key_gitbio.png b/figures/preference_ssh_key_gitbio.png
new file mode 100644
index 0000000000000000000000000000000000000000..2dfa9ed7f55a40076c39707b36bdd1cd8eb6207c
Binary files /dev/null and b/figures/preference_ssh_key_gitbio.png differ
diff --git a/figures/test_ssh_keys.png b/figures/test_ssh_keys.png
new file mode 100644
index 0000000000000000000000000000000000000000..05e30bf66e36811c0fe6375eb5059dccc65fd1ef
Binary files /dev/null and b/figures/test_ssh_keys.png differ