6 Installation et connection

6.1 Introduction

Ayant une utilisation assez minimale de git, et plutôt réservée au partage de documentation, je recommande fortement de lire le support réalisé par l’Insee dans la documentation UtilitR, indéxé dans la partie Gallery du site de Quarto. https://www.book.utilitr.org/03_fiches_thematiques/fiche_git_utilisation.

6.1.1 Principes et atouts de Git

:GIT WIKI

Sur son utilisation le plus courante et là où il est le plus documenté, l’outil Git permet de réaliser des opérations entre fichiers stockés dans un répertoire local (ou de travail) et un répertoire - plus ou moins - distant (remote). Dans un travail en équipe, sous cet aspect “cloud” , il permettra donc relier plusieurs utilisateurs sur un même projet. Sous son aspect originel de logiciel de contrôle de versions, ces opérations se feront sur des éléments ayant fait l’objet d’un changement entre deux temps choisis par l’utilisateur.

Attention l’outil git est totalement indépendant des plateformes¹ qui font sa popularité, on peut travailler exclusivement en local sur une même machine, en choississant un répertoire de travail/développement et un répertoire qui fera seulement office de stockage à un instant t. Mieux encore, sans logique de transferts et sous le seul angle de contrôle de versions d’un ou plusieurs fichiers, n’importe quel répertoire de travail peut être gité² pour contrôler toutes les étapes de développement d’un projet.

Cette partie s’inscrivant dans un support dédié à la construction d’une documentation avec un outil de programmation lettrée , on n’abordera donc pas toutes les possibilités et les manipulations offertes par git. C’est donc plutôt sous l’angle d’opérations de transferts de fichiers pour déployer un contenu Quarto qu’est abordé cette partie.

Atouts:

Les opérations de transferts sont effectuées sur des deltas, c’est à dire sur des modifications qui ont été déclarées par l’utilisateur à un instant t (commit). Ces modifications prennent la forme de création, suppression ou changement du contenu de fichiers.
On peut exclure des fichiers de ces opérations de versionnage et de transferts.
Git permet de garder la trace de toutes les modifications apportées à des fichiers:
- Historique des opérations récupérées sous forme d’une timeline, dont la nature de la modification est indiquée par un titre. Attention ces traces ne sont pas effectuée pas les enregistrements de fichiers mais par une opération spécifique et engendrée par l’utilisateur. Dans le jargon git, cette opération est appelée commit. Le versionnage se fera entre 2 commits même si ces fichiers ont été enregistrés de multiples fois entre ces deux temps.
- On peut accéder à tous les éléments modifiés. Si on supprime un fichier, git considérera qu’on a supprimé l’ensemble du texte d’un fichier et non physiquement un fichier. On pourra accéder à tout moment à la totalité du texte supprimé via la suppression du fichier.
- La visualisation des modifications intervenues dans des fichiers est facilitée par des codes couleurs: Rouge pour l’état au commit précédent, Vert pour l’état au nouveau commit.
Les branches: Dans un répertoire versionné par git, une branche dite principale automatiquement créée (main ou master³). On peut créer et travailler sur des branches parallèles et contrôler la fusion des éléments modifiés avec la branche principale. Dans un travail collaboratif via une opération de clonage, le/la propriétaire du dépôt distant sera en charge de valider et de réaliser ces opérations de fusion avec la branche principale. Toutes ces opérations seront également indéxées dans le versionnage, et on pourra suivre l’historique de création, modification et fusion des branches secondaires avec la branche principale.
Les conflits: oui c’est un atout de git…

Clonage et duplication

En collaboratif la branche principale est clonée par les personnes participant au projet, le propriétaire du répertoire distant donnant les autorisations dans ce sens aux autres participant.e.s. Le travail sur branches sera ici plus que recommandé, en particuliers lorsque plusieurs personnes travailleront sur un même fichier. Le propriétaire du dépôt réalisera les fusions, et donc la mise à jour de la branche principale. Sur les célèbres plateformes, si le dépôt est public il pourra être librement cloné. et également un trav Git permet aussi un travail collaboratif plus ouvert, hors équipe, en donnant la possibilité à quiconque de proposer une modification. Le répertoire (public) pourra être dupliqué (fork). Les modifications des fichiers seront systématiquement envoyés sur une branche secondaire du dépôt distant. Au propriétaire de les accepter ou non.

6.1.2 Github versus Gitlab

6.1.2.1 Github

:GITHUB WIKI

Propriété de Microsoft depuis 2018. Risque de tout perdre si Microsoft décide de supprimer l’outil. L’exemple de l’IDE Atom supprimé en 2019 après son rachat est un cas d’école récent.
- Seulement sur le site plateforme. Pas de récupération posible du code source pour installer un git local ou institutionnel (Humanum, Insee, Service informatique de l’Ined…).
Fonctionnalités clés en main, plus facile d’accès a priori pour les personnes moins à l’aise avec le jargon informatique.
- A noter l’existence d’un outil appelé Github Desktop qui facilite la réalisation les opérations git de base, avec en plus la possibilité de switcher à la volée d’un projet à un autre. A titre personnel, je réalise toutes les opérations avec mes depôts Github à l’aide de ce github desktop.
Quarto ou plutôt Posit en général joue la carte 100% Github avec l’intégration d’outils dédiées. Plus généralement les package R pour faciliter la connection initiale entre RStudio et un compte sur une plateforme git sont pensés pour fonctionner avec cette plateforme. Avec le package usethis on peut générer un dépôt github sans passer par la case clonage, et donc par la création du dépôt sur la plateforme au préalable.
Du côté moins, en mode private (restreint) on ne peut pas déployer de pages sans passer à la caisse. C’est très ennuyeux.
Du côté plus, toujours en mode private Github ne limite pas (encore) le nombre de collaboration. Sur Gitlab, ce nombre a été récemment limité à 5 personnes.

6.1.2.2 Gitlab

:GITLAB WIKI

Même si la composition du capital peut faire grincer quelques dents, Gitlab reste relativement indépendant d’un géant comme Microsoft.
Récupération du code source de Gitlab, ce qui rend possible la création d’une plateforme Git sur un serveur institutionnel .
Pour le déploiement de contenu type html/Qharto, on aura quelques étapes supplémentaires à réaliser.
Côté plus, en mode private on peut déployer des pages sans passer à la caisse contrairement à Github. On peut également gérer très librement ses adresses url. C’est top.
Côté moins, toujours en mode private, forte limitation du nombre de collaborateurs à 5 (anciennement 10). C’est ennuyeux.
Retour d’expérience un peu désagréable: avec un compte strictement individuel, possible prise contact par l’équipe commerciale de Gitlab, avec relances si on ne souhaite pas donner suite à leur proposition de rendez-vous.

6.2 Installation

Git étant indépendant des fameuses plateformes Github et Gitlab, il doit être installé. Mais peut-être est-il déjà installé? C’est normalement le cas avec RStudio. Je conseille néanmoins d’installer la dernière version de git directement, ce qui permettra également de l’utiliser en dehors de RStudio.
- Vérification dans un terminal (dont Rstudio): git --version
- Sinon téléchargement sur le site officiel: https://git-scm.com/download/

Après l’installation ou la vérification de l’installation de Git:

Ne pas oublier d’associer git à une adresse mail, et accessoirement à votre civilité ou à un avatar.

Dans un terminal (Rstudio, invite commande windows,…):

git config --global user.email EMAIL-ADRESSE

git config --global user.name "PRENOM et/NOM"

6.3 Connection initiale avec une plateforme

Note

Procédures de connection via https et clé SSH effectuées fin 2023/début 2024 et mai 2024 via le serveur margaux de l’Ined.
- HTTPS (token/mdp):
  - package usethis: github.
  - package gitcreds: github et gitlab.
- SSH:
  - protocole: ed25519.
Mobile Ined:
- Connection https existantes pour Github et Gitlab => nouveaux token générés.
- Pas de connection SSH existante avec protocole ed25519. Création d’une nouvelle clé.
Serveur margaux Ined (mai 2024)
- Parti de zero.
- HTTPS: Nouveau token généré pour cette connection.
- Pas de connection SSH existante. Création d’une nouvelle clé avec protocole ed25519.

6.3.1 Connection via un token/password

6.3.1.1 Github

Générer un Token

Package usethis

Package usethis

install.packages("usethis")
library(usethis)

En exécutant la commande suivante, une fenêtre s’ouvre pour générer directement un token dans github.

Création d'un token

usethis::create_github_token()

Note: au cas où… ce token n’est bien évidemment plus valide.

Attention à la date d’expiration du token.
- Par défaut 30 jours, on peut augmenter la durée.
- La durée maximale est d’un an.
Cliquer en bas de la page sur Generate token.
On reçoit un mail à la création du token et quelques jours avant sa date d’expiration.

Ajouter le token dans RStudio

Package gitcreds

Package gitcreds

 install.packages("gitcreds")
 library(gitcreds)

Par défaut il va sélectionner Github, on peut toutefois renseigner l’adresse générique de la plateforme

Ajouter le token dans Rstudio

library(gitcreds)
gitcreds_set(url = "https://github.com")

Si aucun token n’a déjà été ajouté, on colle directement dans la console la valeur du token généré dans l’étape précédente .

? Enter password or token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Si on change par la suite de token, plusieurs options sont disponibles:

-> Your current credentials for 'https://github.com':

  protocol: https
  host    : github.com
  username: PersonalAccessToken
  password: <-- hidden -->

-> What would you like to do? 

1: Keep these credentials
2: Replace these credentials
3: See the password / token

L’option 2 permet de changer de token.

6.3.1.2 Gitlab

Générer un token

Le token/password est généré directement sur le compte Gitlab.

Edit profile => Acces Token => add new token.

Edit profile

On peut accéder sur Github à la page de création des token en allant sur Profile Settings (tout en bas) Developer Settings (Menu vertical à gauche).

Ajouter le token dans RStudio

Même procédure qu’avec Github avec le package gitcreds.
On devra explicitement indiquer l’adresse générique de Gitlab dans la fonction.

package gitcreds

install.packages("gitcreds")
library(gitcreds)

Ajouter dans Rstudio le token

library(gitcreds)
gitcreds_set(url = "https://gitlab.com")

Si aucun token n’est déjà été ajouté, on colle directement dans la console la valeur du token généré dans l’étape précédente .

Sélection : 2

-> Removing current credentials...

? Enter new password or token:

? Enter password or token: <Coller ici le token qui a été généré et copié dans gitlab>

Si on change par la suite de token, plusieurs options sont disponibles:

-> Your current credentials for 'https://github.com':

  protocol: https
  host    : github.com
  username: PersonalAccessToken
  password: <-- hidden -->

-> What would you like to do? 

1: Keep these credentials
2: Replace these credentials
3: See the password / toke

6.3.1.3 Vérifier la connection

Vous pouvez vérifier la connection en clonant un dépôt. Coller par exemple le lien suivant lors de la création du projet:

Test dépôt Github

https://github.com/mthevenin/test_connection_formation.git

Test dépôt Gitlab

https://gitlab.com/mthevenin/test_connection_formation.git

6.3.2 Via une clé de cryptage SSH

:GIT SSH

Je ne traite pas du sujet https (token) versus SSH (cryptage), mais visiblement les préférences penchent plutôt vers le https. Je note néanmoins beaucoup plus de tutoriels orientée vers la solution SSH.
On peut paramétrer et utiliser les deux techniques de sécurité, le choix de l’une ou l’autre se fait lors du clônage d’un dépôt distant.
Clé SSH: repose sur un cryptage.
- Les protocoles de cryptage évolue dans le temps. C’est la quatrième et dernière génération qui est proposée par RStudio. Github n’autorise que ce mode de cryptage.
- Cette dernière génération est appelée ed25519.
Une même clé SSH peut-être utilisée pour Github et Gitlab. Lorsqu’on travaille sur plusieurs machines (dont la version serveur de Rstudio à l’Ined) on devra engendrer autant de clés SSH dans RStudio pour établir la connexion.

6.3.2.1 Générer une clé dans Rstudio

Tools
Global Options
Git/SVN dans la barre de menu verticale
Create SSH key: On génère la clé sous la zône d’enregistrement
View public key: On visualise et récupère la clé SSH en la copiant

6.3.2.2 Github

flowchart LR
  A(Avatar) --> B(Settings)
  B --> C(SSH and GPH Keys)
  C --> D(New SSH key)
    D --> E(Coller la clé)
    subgraph AJOUTER LA CLE
    E --- F(Mettre un titre)
    F --> G(ADD SSH KEY)
    end

Cliquer sur l’avatar à droite
Sur la barre verticale qui s’ouvre, aller sur Settings
Aller sur la page SSH and GPH keys
Aller sur New SSH key en haut à droite
Coller la clé générée dans RStudio, si on ajoute plusieurs clés, renseigner le titre pour identifier son rôle
Cliquer sur Add SSH key

Aller sur l’avatar

6.3.2.3 Gitlab

flowchart LR
  A(Avatar) --> B(Preference)
  B --> C(SSH KEY)
  C --> D(Add new key)  
    D --> E(Coller la clé)
    subgraph AJOUTER LA CLE
    E --- F(Mettre un titre)
    F --- G(Changer la date d'expiration)
    G --> H(ADD KEY)
    end

Cliquer sur votre avatar
Aller sur preference
Cliquer sur SSH Keys
Cliquer sur Add new key
Coller votre clé générée dans RStudio
Ajouter un titre si vous comptez avoir plusieurs clés
Modifier la date d’expiration (X si aucune expiration)
Cliquer sur Add key

Avatar=>Préférences

Si vous avez ajouté une passphrase à la création de la clé

Dans le terminal:

eval $(ssh-agent -s)

Output, par exemple: Agent pid 1463.

Ajouter la clé

ssh-add ~/.ssh/id_ed25519

Output: Identity added: /c/Users/thevenin_m/.ssh/id_ed25519 (ined\thevenin_m@MOB0XXXX)

Si un message de ce type apparait, taper yes

The authenticity of host 'github.com (140.82.121.4)' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvXXXXXXX\(*_*)/XXXXXXXXXr4UvCOqU.
This key is not known by any other names.

On peut vérifier que tout est ok avec les messages de bienvenue suivants:

Github:

ssh -T git@github.com

Hi mthevenin! You've successfully authenticated, but GitHub does not provide shell access.

Gitlab:

ssh -T git@gitlab.com

Welcome to GitLab, @mthevenin!

6.3.2.4 Vérifier la connection

Vous pouvez vérifier la connection en clonant un dépôt. Coller par exemple le lien suivant lors de la création du projet:

Test dépôt Github

git@github.com:mthevenin/test_connection_formation.git

Test dépôt Gitlab

git@gitlab.com:mthevenin/test_connection_formation.git

Si lors du premier clonage le message suivant s’affiche, taper yes:

On parle également de forge↩︎
j’ai pas trouvé mieux↩︎
L’assassinat de Georges Floyd en 2020 est passé par là↩︎

--- filters: - nutshell --- # Installation et connection ## Introduction Ayant une utilisation assez minimale de git, et plutôt réservée au partage de documentation, je recommande fortement de lire le support réalisé par l'Insee dans la documentation **UtilitR**, indéxé dans la partie **Gallery** du site de Quarto. <https://www.book.utilitr.org/03_fiches_thematiques/fiche_git_utilisation>. ### Principes et atouts de Git [[:GIT WIKI](https://fr.wikipedia.org/wiki/Git)]{.nut} <br> Sur son utilisation le plus courante et là où il est le plus documenté, l'outil Git permet de réaliser des opérations entre fichiers stockés dans un répertoire local (ou de travail) et un répertoire - plus ou moins - *distant* (**remote**). Dans un travail en équipe, sous cet aspect "*cloud*" , il permettra donc relier plusieurs utilisateurs sur un même projet. Sous son aspect originel de logiciel de contrôle de versions, ces opérations se feront sur des éléments ayant fait l'objet d'un changement entre deux temps choisis par l'utilisateur. Attention l'outil git est totalement indépendant des plateformes^[On parle également de forge] qui font sa popularité, on peut travailler exclusivement en local sur une même machine, en choississant un répertoire de travail/développement et un répertoire qui fera seulement office de stockage à un instant t. Mieux encore, sans logique de transferts et sous le seul angle de contrôle de versions d'un ou plusieurs fichiers, n'importe quel répertoire de travail peut être ***gité***^[j'ai pas trouvé mieux] pour contrôler toutes les étapes de développement d'un projet. Cette partie s'inscrivant dans un support dédié à la construction d'une documentation avec un outil de *programmation lettrée *, on n'abordera donc pas toutes les possibilités et les manipulations offertes par git. C'est donc plutôt sous l'angle d'opérations de transferts de fichiers pour déployer un contenu Quarto qu'est abordé cette partie. Atouts: - Les opérations de transferts sont effectuées sur des **deltas**, c'est à dire sur des modifications qui ont été déclarées par l'utilisateur à un instant t (**commit**). Ces modifications prennent la forme de **création**, **suppression** ou **changement du contenu** de fichiers. - On peut exclure des fichiers de ces opérations de versionnage et de transferts. - Git permet de garder la trace de toutes les modifications apportées à des fichiers: - Historique des opérations récupérées sous forme d'une timeline, dont la nature de la modification est indiquée par un titre. Attention ces traces ne sont pas effectuée pas les enregistrements de fichiers mais par une opération spécifique et engendrée par l'utilisateur. Dans le jargon git, cette opération est appelée **commit**. Le versionnage se fera entre 2 **commits** même si ces fichiers ont été enregistrés de multiples fois entre ces deux temps. - On peut accéder à tous les éléments modifiés. Si on supprime un fichier, git considérera qu'on a supprimé l'ensemble du texte d'un fichier et non physiquement un fichier. On pourra accéder à tout moment à la totalité du texte supprimé via la suppression du fichier. - La visualisation des modifications intervenues dans des fichiers est facilitée par des codes couleurs: [**Rouge**]{style="color:#dc3545"} pour l'état au commit précédent, [**Vert**]{style="color:#198754"} pour l'état au nouveau commit. - **Les branches**: Dans un répertoire versionné par git, une branche dite principale automatiquement créée (**main** ou **master**^[L'assassinat de Georges Floyd en 2020 est passé par là]). On peut créer et travailler sur des branches parallèles et contrôler la fusion des éléments modifiés avec la branche principale. Dans un travail collaboratif via une opération de clonage, le/la propriétaire du dépôt distant sera en charge de valider et de réaliser ces opérations de fusion avec la branche principale. Toutes ces opérations seront également indéxées dans le versionnage, et on pourra suivre l'historique de création, modification et fusion des branches secondaires avec la branche principale. - **Les conflits**: oui c'est un atout de git... ::: callout-note #### Clonage et duplication En collaboratif la branche principale est clonée par les personnes participant au projet, le *propriétaire* du répertoire distant donnant les autorisations dans ce sens aux autres participant.e.s. Le travail sur branches sera ici plus que recommandé, en particuliers lorsque plusieurs personnes travailleront sur un même fichier. Le propriétaire du dépôt réalisera les fusions, et donc la mise à jour de la branche principale. Sur les célèbres plateformes, si le dépôt est public il pourra être librement cloné. et également un trav Git permet aussi un travail collaboratif plus ouvert, hors équipe, en donnant la possibilité à quiconque de proposer une modification. Le répertoire (public) pourra être dupliqué (**fork**). Les modifications des fichiers seront systématiquement envoyés sur une branche secondaire du dépôt distant. Au propriétaire de les accepter ou non. ::: ### Github versus Gitlab #### Github {{<fa brands github>}} [[:GITHUB WIKI](https://fr.wikipedia.org/wiki/GitHub)]{.nut} * Propriété de Microsoft depuis 2018. Risque de tout perdre si Microsoft décide de supprimer l'outil. L'exemple de l'IDE Atom supprimé en 2019 après son rachat est un cas d'école récent. * Seulement sur le site plateforme. Pas de récupération posible du code source pour installer un git local ou institutionnel (Humanum, Insee, Service informatique de l'Ined...). * Fonctionnalités clés en main, plus facile d'accès *a priori* pour les personnes moins à l'aise avec le jargon informatique. * A noter l'existence d'un outil appelé **Github Desktop** qui facilite la réalisation les opérations git de base, avec en plus la possibilité de switcher à la volée d'un projet à un autre. A titre personnel, je réalise toutes les opérations avec mes depôts Github à l'aide de ce **github desktop**. * Quarto ou plutôt Posit en général joue la carte 100% Github avec l'intégration d'outils dédiées. Plus généralement les package R pour faciliter la connection initiale entre RStudio et un compte sur une plateforme git sont pensés pour fonctionner avec cette plateforme. Avec le package **`usethis`** on peut générer un dépôt github sans passer par la case clonage, et donc par la création du dépôt sur la plateforme au préalable. * Du côté moins, en mode **private** (restreint) on ne peut pas déployer de pages sans passer à la caisse. C'est très ennuyeux. * Du côté plus, toujours en mode **private** Github ne limite pas (encore) le nombre de collaboration. Sur Gitlab, ce nombre a été récemment limité à 5 personnes. #### Gitlab {{<fa brands gitlab>}} [[:GITLAB WIKI](https://fr.wikipedia.org/wiki/GitLab)]{.nut} * Même si la composition du capital peut faire grincer quelques dents, Gitlab reste relativement indépendant d'un géant comme Microsoft. * Récupération du code source de Gitlab, ce qui rend possible la création d'une plateforme Git sur un serveur institutionnel . * Pour le déploiement de contenu type html/Qharto, on aura quelques étapes supplémentaires à réaliser. * Côté plus, en mode private on peut déployer des pages sans passer à la caisse contrairement à Github. On peut également gérer très librement ses adresses url. C'est top. * Côté moins, toujours en mode private, forte limitation du nombre de collaborateurs à 5 (anciennement 10). C'est ennuyeux. * Retour d'expérience un peu désagréable: avec un compte strictement individuel, possible prise contact par l'équipe commerciale de Gitlab, avec relances si on ne souhaite pas donner suite à leur proposition de rendez-vous. ## Installation * Git étant indépendant des fameuses plateformes Github et Gitlab, il doit être installé. Mais peut-être est-il déjà installé? C'est normalement le cas avec RStudio. Je conseille néanmoins d'installer la dernière version de git directement, ce qui permettra également de l'utiliser en dehors de RStudio. * Vérification dans un terminal (dont Rstudio): `git --version` * Sinon téléchargement sur le site officiel: <https://git-scm.com/download/> Après l'installation ou la vérification de l'installation de Git: * Ne pas oublier d'associer git à une adresse mail, et accessoirement à votre civilité ou à un avatar. Dans un terminal (Rstudio, invite commande windows,...): ```{.bash} git config --global user.email EMAIL-ADRESSE ``` ```{.bash} git config --global user.name "PRENOM et/NOM" ``` ## Connection initiale avec une plateforme ::: callout-note * Procédures de connection via **https** et **clé SSH** effectuées fin 2023/début 2024 et mai 2024 via le serveur margaux de l'Ined. * HTTPS (token/mdp): * package `usethis`: github. * package `gitcreds`: github et gitlab. * SSH: * protocole: ed25519. * Mobile Ined: * Connection https existantes pour Github et Gitlab => nouveaux token générés. * Pas de connection SSH existante avec protocole ed25519. Création d'une nouvelle clé. * Serveur margaux Ined (mai 2024) * Parti de zero. * HTTPS: Nouveau token généré pour cette connection. * Pas de connection SSH existante. Création d'une nouvelle clé avec protocole ed25519. ::: ### Connection via un token/password {#sec-token} #### Github {{<fa brands github>}} **Générer un Token** * Package `usethis` ```{r filename="Package usethis "} #| eval: false install.packages("usethis") library(usethis) ``` En exécutant la commande suivante, une fenêtre s'ouvre pour générer directement un token dans github. ```{r filename="Création d'un token"} #| eval: false usethis::create_github_token() ``` ::: {.box_img} ![](img2/token_github1.png){group=gh1} ::: ::: {.box_img} ![](img2/token_github2.png){group=gh1} ::: Note: au cas où... ce token n'est bien évidemment plus valide. * Attention à la date d'expiration du token. * Par défaut 30 jours, on peut augmenter la durée. * La durée maximale est d'un an. * Cliquer en bas de la page sur **Generate token**. * On reçoit un mail à la création du token et quelques jours avant sa date d'expiration. **Ajouter le token dans RStudio** * Package **`gitcreds`** ```{r filename="Package gitcreds"} #| eval: false install.packages("gitcreds") library(gitcreds) ``` * Par défaut il va sélectionner Github, on peut toutefois renseigner l'adresse générique de la plateforme ```{r filename="Ajouter le token dans Rstudio"} #| eval: false library(gitcreds) gitcreds_set(url = "https://github.com") ``` Si aucun token n'a déjà été ajouté, on colle directement dans la console la valeur du token généré dans l'étape précédente . ```{.mf} ? Enter password or token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ``` Si on change par la suite de token, plusieurs options sont disponibles: ```{.mf} -> Your current credentials for 'https://github.com': protocol: https host : github.com username: PersonalAccessToken password: <-- hidden --> -> What would you like to do? 1: Keep these credentials 2: Replace these credentials 3: See the password / token ``` **L'option 2 permet de changer de token**. #### Gitlab {{<fa brands gitlab>}} **Générer un token** Le token/password est généré directement sur le compte Gitlab. **Edit profile** => **Acces Token** => **add new token**. :::: {layout="[30,-1,30,-1,30]" layout-valign="bottom"} ::: {.box_img} ![Edit profile](img2/token_gitlab1.png){group=gl1} ::: ::: {.box_img} ![Access token](img2/token_gitlab2.png){group=gl1} ::: ::: {.box_img} ![Personal access token](img2/token_gitlab3.png){group=gl1} ::: ::: :::: {layout="[20,-1,20,]" layout-valign="bottom"} ::: {.box_img} ![Sélection Read/write repository](img2/token_gitlab4.png){group=gl1} ::: ::: {.box_img} ![Récupérer le token](img2/token_gitlab5.png){group=gl1} ::: :::: On peut accéder sur Github à la page de création des token en allant sur **Profile** {{< fa solid arrow-right >}} **Settings** (tout en bas) {{< fa solid arrow-right >}} **Developer Settings** (Menu vertical à gauche). **Ajouter le token dans RStudio** * Même procédure qu'avec Github avec le package **`gitcreds`**. * On devra explicitement indiquer l'adresse générique de Gitlab dans la fonction. ```{r filename="package gitcreds"} #| eval: false install.packages("gitcreds") library(gitcreds) ``` ```{r filename="Ajouter dans Rstudio le token"} #| eval: false library(gitcreds) gitcreds_set(url = "https://gitlab.com") ``` Si aucun token n'est déjà été ajouté, on colle directement dans la console la valeur du token généré dans l'étape précédente . ```{.mf} Sélection : 2 -> Removing current credentials... ? Enter new password or token: ``` ```{.mf} ? Enter password or token: <Coller ici le token qui a été généré et copié dans gitlab> ``` Si on change par la suite de token, plusieurs options sont disponibles: ```{.mf} -> Your current credentials for 'https://github.com': protocol: https host : github.com username: PersonalAccessToken password: <-- hidden --> -> What would you like to do? 1: Keep these credentials 2: Replace these credentials 3: See the password / toke ``` #### Vérifier la connection Vous pouvez vérifier la connection en clonant un dépôt. Coller par exemple le lien suivant lors de la création du projet: ```{.mf filename="Test dépôt Github"} https://github.com/mthevenin/test_connection_formation.git ``` ```{.mf filename="Test dépôt Gitlab"} https://gitlab.com/mthevenin/test_connection_formation.git ``` ### Via une clé de cryptage SSH [[:GIT SSH](https://en.wikipedia.org/wiki/Ssh-keygen)]{.nut} <br> * Je ne traite pas du sujet https (token) versus SSH (cryptage), mais visiblement les préférences penchent plutôt vers le https. Je note néanmoins beaucoup plus de tutoriels orientée vers la solution SSH. * On peut paramétrer et utiliser les deux techniques de sécurité, le choix de l'une ou l'autre se fait lors du clônage d'un dépôt distant. * **Clé SSH**: repose sur un cryptage. * Les protocoles de cryptage évolue dans le temps. C'est la quatrième et dernière génération qui est proposée par RStudio. Github n'autorise que ce mode de cryptage. * Cette dernière génération est appelée **ed25519**. * Une même clé SSH peut-être utilisée pour Github et Gitlab. Lorsqu'on travaille sur plusieurs machines (dont la version serveur de Rstudio à l'Ined) on devra engendrer autant de clés SSH dans RStudio pour établir la connexion. #### Générer une clé dans Rstudio * **Tools** {{< fa solid turn-down >}} * **Global Options** {{< fa solid turn-down >}} * **Git/SVN** dans la barre de menu verticale {{< fa solid turn-down >}} * **Create SSH key**: On génère la clé sous la zône d'enregistrement {{< fa solid turn-down >}} * **View public key**: On visualise et récupère la clé SSH en la copiant {{< fa solid turn-down >}} :::: {layout="[50,-1,50]" layout-valign="bottom" } ::: {.box_img} ![Création de la clé SSH](img2/ssh_rstudio1.png){group=ssh1} ::: ::: {.box_img} ![Récupération de la clé SSH](img2/ssh_rstudio2.png){group=ssh1} ::: :::: #### Github {{<fa brands github>}} ```{mermaid} %%| fig-width: 6.5 flowchart LR A(Avatar) --> B(Settings) B --> C(SSH and GPH Keys) C --> D(New SSH key) D --> E(Coller la clé) subgraph AJOUTER LA CLE E --- F(Mettre un titre) F --> G(ADD SSH KEY) end ``` * Cliquer sur l'avatar à droite {{< fa solid turn-down >}} * Sur la barre verticale qui s'ouvre, aller sur **Settings** {{< fa solid turn-down >}} * Aller sur la page **SSH and GPH keys** {{< fa solid turn-down >}} * Aller sur **New SSH key** en haut à droite {{< fa solid turn-down >}} * Coller la clé générée dans RStudio, si on ajoute plusieurs clés, renseigner le titre pour identifier son rôle {{< fa solid turn-down >}} * Cliquer sur **Add SSH key** :::: {layout="[50,-1,50]" layout-valign="bottom" } ::: {.box_img} ![Aller sur l'avatar](img2/ssh_github1.png){group=gh2} ::: ::: {.box_img} ![Aller sur settings](img2/ssh_github2.png){group=gh2} ::: :::: :::: {layout="[50,-1,50]" layout-valign="bottom" } ::: {.box_img} ![Page SSH et GPH keys](img2/ssh_github3.png){group=gh2} ::: ::: {.box_img} ![Ajouter la clé](img2/ssh_github4.png){group=gh2} ::: :::: #### Gitlab {{<fa brands gitlab>}} ```{mermaid} %%| fig-width: 6.5 flowchart LR A(Avatar) --> B(Preference) B --> C(SSH KEY) C --> D(Add new key) D --> E(Coller la clé) subgraph AJOUTER LA CLE E --- F(Mettre un titre) F --- G(Changer la date d'expiration) G --> H(ADD KEY) end ``` * Cliquer sur votre avatar {{< fa solid turn-down >}} * Aller sur *preference* {{< fa solid turn-down >}} * Cliquer sur **SSH Keys** {{< fa solid turn-down >}} * Cliquer sur **Add new key** {{< fa solid turn-down >}} * Coller votre clé générée dans RStudio {{< fa solid turn-down >}} * Ajouter un titre si vous comptez avoir plusieurs clés {{< fa solid turn-down >}} * Modifier la date d'expiration (X si aucune expiration) {{< fa solid turn-down >}} * Cliquer sur **Add key** :::: {layout="[33,33,33]" layout-valign="bottom"} ::: {.box_img} ![Avatar=>Préférences](img2/ssh_gitlab1.png){group=gl2} ::: ::: {.box_img} ![Aller dans SSH keys](img2/ssh_gitlab2.png){group=gl2} ::: ::: {.box_img} ![Ajouter la clé](img2/ssh_gitlab3.png){group=gl2} ::: :::: ::: {.callout-note collapse=TRUE} #### Si vous avez ajouté une passphrase à la création de la clé Dans le terminal: ```{.mf} eval $(ssh-agent -s) ``` Output, par exemple: **`Agent pid 1463`**. * Ajouter la clé ```{.mf} ssh-add ~/.ssh/id_ed25519 ``` Output: **`Identity added: /c/Users/thevenin_m/.ssh/id_ed25519 (ined\thevenin_m@MOB0XXXX)`** Si un message de ce type apparait, taper **yes** ```{.bash} The authenticity of host 'github.com (140.82.121.4)' can't be established. ED25519 key fingerprint is SHA256:+DiY3wvvXXXXXXX\(*_*)/XXXXXXXXXr4UvCOqU. This key is not known by any other names. ``` ::: On peut vérifier que tout est ok avec les messages de bienvenue suivants: * Github: ```{.mf} ssh -T git@github.com ``` ```{.mf} Hi mthevenin! You've successfully authenticated, but GitHub does not provide shell access. ``` * Gitlab: ```{.mf} ssh -T git@gitlab.com ``` ```{.mf} Welcome to GitLab, @mthevenin! ``` <br> #### Vérifier la connection Vous pouvez vérifier la connection en clonant un dépôt. Coller par exemple le lien suivant lors de la création du projet: ```{.mf filename="Test dépôt Github"} git@github.com:mthevenin/test_connection_formation.git ``` ```{.mf filename="Test dépôt Gitlab"} git@gitlab.com:mthevenin/test_connection_formation.git ``` * Si lors du premier clonage le message suivant s'affiche, taper **yes**: ::: {.box_img} ![](img2/ssh1.png) :::