1 Créer une clé ssh

  • Se connecter à au cluster :
ssh -X login@core.cluster.france-bioinformatique.fr
  • Vérifier si l’on dispose déjà d’une paire de clés (elles sont dans le dossier ~/.ssh)
ls -al ~/.ssh

Elles vont par paires comme par exemple :

  • id_rsa et id_rsa.pub

  • id_ecdsa et id_ecdsa.pub

  • id_ed25519 et id_ed25519.pub

  • Si vous n’avez pas de clé existante, générer la paire de clés avec ssh-keygen :

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

2 Configurer le lien entre votre clef et Github

Pour pouvoir effectuer des opérations sur GitHub (clone, push, pull) à partir de git sous un terminal, il vous faut configurer votre compte GitHub.

L’authentification des opérations menées à partir de Git sur Github passe exclusivement par l’échange de clefs ssh. Il vous faut donc faire connaitre à Github votre clef publique en la copiant dans son interface.

cat ~/.ssh/id_rsa.pub
  • vérifier que tout fonctionne :
 ssh -T git@github.com
# A la première connexion, vous pouvez voir un warning de ce type :
#> The authenticity of host 'github.com (IP ADDRESS)' can't be established.
#> RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
#> Are you sure you want to continue connecting (yes/no)?

# Verify that the fingerprint in the message you see matches GitHub's RSA public key fingerprint ( https://docs.github.com/en/github/authenticating-to-github/githubs-ssh-key-fingerprints ). If it does, then type yes:
#> Hi username! You've successfully authenticated, but GitHub does not
#> provide shell access.

Procédure détaillée Mac, Windows, Linux

3 Versionner ses documents avec Git

3.1 Créer un dépôt distant sur Github

Notez la première ligne avec l’adresse pour récupérer le dépôt en sélectionnant le mode SSH.

Remarque : Il est aussi possible de faire cela en localement avec git init mais dans ce cas il faudra ensuite lier ce dépôt à un remote distant si l’on le souhaite. Nous vous conseillons plutôt de créer un dépot vide coté GitHub, puis de le cloner en local (partie suivante)

mkdir testRepo
cd testRepo
# Initialized empty Git repository in /Users/vloux/tmp/testRepo/.git/
git init

# Add a new local git repo to an existing and empty Github repo : 
git remote add origin git@github.com:vloux/testRepo.git

#Verify new remote
git remote -v

git branch -M main
git push -u origin main

3.2 Cloner le dépôt depuis GitHub vers l’IFB

mkdir -p ~/M5S3/GitHub
cd ~/M5S3/GitHub

git clone git@github.com:... # git clone git@github.com:CedricMidoux/DuBii2021.git

Le dépôt est vide et disponible localement.

cd DuBii2021/
ls -la
# total 0
# drwxrwxrwx 1 cmidoux cmidoux 4096 Mar  5 17:21 .
# drwxrwxrwx 1 cmidoux cmidoux 4096 Mar  5 17:21 ..
# drwxrwxrwx 1 cmidoux cmidoux 4096 Mar  5 17:21 .git

3.3 Ajouter un document (en local)

On ajoute un premier fichier et on utilise git status pour connaître l’état de notre dépôt.

echo 'my first line' > firstFile

git status
# On branch master
#
# No commits yet
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#   firstFile
#
# nothing added to commit but untracked files present (use "git add" to track)

Le nouveau fichier n’est pas suivi. Il faut l’ajouter avec git add puis lorsque toutes les modifications sont suivies, on peut commit avec git commit.

git add firstFile
git status
# On branch master
# 
# No commits yet
#  
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#   new file:   firstFile

git commit -m "Premier commit"
# [master (root-commit) e8b7769] Premier commit
#  1 file changed, 1 insertion(+)
#  create mode 100644 firstFile

git status
# On branch master
# nothing to commit, working tree clean

3.4 Modifier un fichier et observer les différences

echo 'seconde modif' >> firstFile

git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git restore <file>..." to discard changes in working directory)
#   modified:   firstFile
#
#no changes added to commit (use "git add" and/or "git commit -a")

git diff
# diff --git a/firstFile b/firstFile
# index b1a9f66..9cc14c7 100644
# --- a/firstFile
# +++ b/firstFile
# @@ -1 +1,2 @@
#  my first line
# +seconde modif

git add firstFile
git commit -m "ajout de la deuxième ligne"
# [master ddcd769] ajout de la deuxième ligne
#  1 file changed, 1 insertion(+)

3.5 Pousser les modifications locales sur le dépôt distant

La commande git push pousse les modifications de la branche master (la branche par défaut locale) sur la branche origin (le nom de la branche distante).

git push origin master #`git push` est suffisant par défaut
# Enumerating objects: 6, done.
# Counting objects: 100% (6/6), done.
# Delta compression using up to 4 threads
# Compressing objects: 100% (2/2), done.
# Writing objects: 100% (6/6), 487 bytes | 10.00 KiB/s, done.
# Total 6 (delta 0), reused 0 (delta 0)
# To github.com:CedricMidoux/DuBii2021.git
#  * [new branch]      master -> master

On peut lister les différents dépôts distants avec

git remote -v
# origin    git@github.com:CedricMidoux/DuBii2021.git (fetch)
# origin    git@github.com:CedricMidoux/DuBii2021.git (push)

3.6 Verification sur Github des infos

  • Connectez vous sur l’interface de Github :
    • Trouvez votre dépôt
    • Vérifiez que vous trouvez bien le fichier que vous avez modifié, les commits

3.7 Modification du dépôt par l’interface

  • Ajouter un README.md (avec markdown)
  • Le commiter depuis l’interface
  • L’éditer
  • Commiter la modification

3.8 Récupérer sur le repo local des infos de la branche distante

git fetch
# remote: Enumerating objects: 10, done.
# remote: Counting objects: 100% (10/10), done.
# remote: Compressing objects: 100% (8/8), done.
# remote: Total 9 (delta 0), reused 0 (delta 0), pack-reused 0
# Unpacking objects: 100% (9/9), 2.10 KiB | 7.00 KiB/s, done.
# From github.com:CedricMidoux/DuBii2021
#    110b5a5..4606251  master     -> origin/master

git merge
# Updating 110b5a5..4606251
# Fast-forward
#  README.md | 3 +++
#  1 file changed, 3 insertions(+)
#  create mode 100644 README.md

cat README.md
# # DuBii2021
# 
# Ceci est le `README`. On peut facilement l'éditer en ligne avec du *Markdown* et commiter chaque changement ...

équivalent à :

git pull # fetch + merge

3.9 Le journal des modifications

On peut lister les commit avec git log.

git log
# commit 4606251a3f1a63874803c1a2397072b7ac60ebf1 (HEAD -> master, origin/master)
# Author: CedricMidoux <34483895+CedricMidoux@users.noreply.github.com>
# Date:   Mon Mar 8 11:30:27 2021 +0100
# 
#     Update README.md
# 
# ...

Pour chaque commit on a un identifiant (SHA), l’auteur, la date et le commentaire (d’où l’interet de correctement nommer ses commits)

On peut comparer deux commits différents (en précisant ou non le fichier a comparer). Si on précise qu’un commit, par défaut on compare à HEAD.

git diff [CommitNumber] [CommitNumber] [File]

git diff 26bce3 # = git diff 26bce3 HEAD
# diff --git a/README.md b/README.md
# index 3bfeb78..4e55303 100644
# --- a/README.md
# +++ b/README.md
# @@ -1,3 +1,3 @@
#  # DuBii2021
#  
# -Ceci est le README. On peut facilement l'éditer en ligne
# +Ceci est le `README`. On peut facilement l'éditer en ligne avec du *Markdown* et commiter chaque changement ...

git diff 110b5a 1fcc15 firstFile
# diff --git a/firstFile b/firstFile
# index 9cc14c7..b1a9f66 100644
# --- a/firstFile
# +++ b/firstFile
# @@ -1,2 +1 @@
#  my first line
# -seconde modif

3.10 Nommer des versions (tags)

git tag version1 -m "Initial version"
git log 
# commit 4606251a3f1a63874803c1a2397072b7ac60ebf1 (HEAD -> master, tag: version1, origin/master)

git push --tags
# Enumerating objects: 1, done.
# Counting objects: 100% (1/1), done.
# Writing objects: 100% (1/1), 168 bytes | 3.00 KiB/s, done.
# Total 1 (delta 0), reused 0 (delta 0)
# To github.com:CedricMidoux/DuBii2021.git
#  * [new tag]         version1 -> version1

Sur l’interface en ligne de GitHub, on retrouve les tags.

4 Documents Computationel : Rédaction d’un notebook avec RStudio

  1. Connectez vous au RStudio de l’IFB (https://rstudio.cluster.france-bioinformatique.fr/).

  2. Clonez votre projet :

    • New Project (en haut à droite)
    • Version Control
    • Git
    • Repository URL (clone with SSH : git@github.com: ...) et Subdirectory : ~/M5S3/RStudio

RStudio-IFB va utiliser la même clé SSH ~/.ssh/id_rsa.
On peut avoir plus d’informations en se rendant dans Tools > Global Options > Git

  1. Explorez le dépôt depuis ce 3e device remote

  2. Créez un document R Markdown :

    • File
    • New file
    • R Markdown

Dans ce document on a :

  • Une entête générale
  • Du texte, mis en forme avec markdown
  • Du code R dans des chunks
  • Des résultats et outputs

Grâce à l’onglet git de Rstudio, vous pouvez suivre l’état des fichiers, commit, diff, push/pull, …

Chaque chunk peut être exécuté individuellement grâce à la flèche verte.
Les options associées à chaque chunks sont disponible avec la roue crantée.

  1. Modifier le document (en plusieurs commits)

    • ajoutez un chunk knitr::kable(head(iris)) pour visualiser un table
    • ajoutez un chunk plot(cars) pour un plot
    • ajoutez un chunk bash pwd par exemple
    • ajoutez des commentaires mis en forme avec markdown
    • ajoutez une formule tel que $\Delta = b^2 - 4ac$

  2. Lorsque vous êtes satisfait de votre rapport, générez la version HTML en cliquant sur Knit. Commitez, pushez, …

  3. Visualisez les modifications côté GitHub

  4. Pour rentre une page HTML visualisable avec GitHub Pages

    • Dans les options du repo, dans le chapitre “GitHub Pages,” activer la source correspondant à la branch main (ou master suivant votre configuration)
    • la page est disponible à l’adresse https://[user].github.io/[repo]/[page].html

Votre rapport est disponible, versionné et partageable !

Suivant l’interlocuteur, partagez le .Rmd ou le .html

5 Bonus 1: configurer Git sur votre poste local (ou votre ordinateur perso) et versionner des fichiers

Vous pouvez cloner en local votre dépôt Git et le modifier depuis le poste local. une fois la modification faite, la pousser avec un git push.

  • Observer sur le dépôt centralisé GitHub que les modifications ont bien été prises en compte
  • Les rapatrier sur votre dépôt IFB, depuis la ligne de commande ou le serveur Rstudio

6 Bonus 2 : se connecter en ssh au cluster de l’IFB grace aux clés ssh

Comme l’on a utiliser les clés SSH pour se connecter à GitHub depuis l’IFB, il est possible de se connecter à l’IFB depuis votre ordinateur.

  • On crée une nouvelle paire de clés
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
  • On l’envoie de manière sécurisé en rentrant pour une dernière fois sa phrase de passe.
ssh-copy-id -i id_rsa.pub <login>@core.cluster.france-bioinformatique.fr
  • Maintenant on peut se connecter plus facilement
ssh <login>@core.cluster.france-bioinformatique.fr

  • La liste des clés autorisées est regroupé dans ~/.ssh/authorized_keys

  • Le bonus du bonus : utiliser des alias. On peut renseigner dans le fichier .ssh/config des paramètres de connexion tel le login et l’adresse du serveur. Voici un exemple de .ssh/config :

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes
    ForwardX11Timeout 8h
    ServerAliveInterval 120

Host migale
    HostName migale.jouy.inrae.fr
    User <login>
    
Host ifb
    HostName core.cluster.france-bioinformatique.fr
    User <login>
  • En combinant ceci et les clés SSH, on peut se connecter avec :
ssh ifb

Vous pouvez mutualiser votre paire de clé depuis plusieurs terminaux mais la clé privée est extrêmement confidentielle et il faut être très vigilent aux fuites et pertes.

 

A work by Migale Bioinformatics Facility

https://migale.inrae.fr

Our two affiliations to cite us:

Université Paris-Saclay, INRAE, MaIAGE, 78350, Jouy-en-Josas, France

Université Paris-Saclay, INRAE, BioinfOmics, MIGALE bioinformatics facility, 78350, Jouy-en-Josas, France