Fiche 1 Découverte de Git et Gitlab pour RStudio

1.1 Qu’est-ce Git, qu’est ce que Gitlab, quels usages pour chacun ?

1.1.1 Principes

Les deux outils servent à versionner des scripts et gèrent des branches de développement d’un projet.

Git est un logiciel de suivi de version lié à chaque poste de travail. Il enregistre une image de l’état d’un projet à chaque commit et identifie les différences entre versions, fichier par fichier, à la manière de la fonction suivi des modifications d’un logiciel de traitement de texte. On peut naviguer d’un stade de développement à l’autre (head) et restaurer un état antérieur… Avec git seul, on versionne ses scripts uniquement en local (sur sa propre machine, ou sur le réseau ?) sans recourir à gitlab.

Gitlab est distribué sur un serveur (intranet ou web). On peut y consigner, version après version, les scripts versionnés en local, pour les partager avec une communauté. On peut également éditer directement des scripts sur le serveur (readme.md, licence). Gitlab propose également des fonctionnalités de conduite de projet, d’échanges entre développeurs, avec les clients…, le tout couplé au versionnage du projet. Gitlab propose enfin de puissantes fonctionnalités d’intégration continue devOps.

1.1.2 Les interfaces entre Git et Gitlab

Git seul est peu user-friendly. Le logiciel propose une interface en ligne de commandes :

ou une interface utilisateur plutôt frustre :

qui ouvre

Généralement, on utilise un logiciel tiers plus civilisé qui fait appel à git :

  • Rstudio
  • github desktop

1.2 A propos de Git

1.2.1 Installation de Git

  1. Installer git depuis https://git-scm.com/downloads.
    Pour mettre à jour, via git cmd : git clone https://github.com/git/git

  2. Déclarer le proxy
    git ne va pas chercher dans les options d’internet explorer ou de RStudio, il faut lui apprendre à franchir le proxy en ligne de commande (Git GUI ou terminal R studio)

git config --global http.proxy http://pfrie-std.proxy.e2.rie.gouv.fr:8080
git config --global https.proxy http://pfrie-std.proxy.e2.rie.gouv.fr:8080
  1. Déclarer et authentifier l’utilisateur de Git en vue de la communication avec un serveur
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
  1. Utiliser l’authentification par :
  • http pour gitlab-forge (basée sur nom d’utilisateur et un token) cf Fiche 2 configuration
  • clé SSH pour gitlab.com ou github (basée sur une clé, à générer par exemple depuis RStudio)

Notas :

1.2.2 Configurer RStudio pour avoir accès à git

On active le contrôle de version pour les projets R dans les options globales du menu Tools de RStudio :

Le bouton Create RSA key permet de générer simplement la paire de clés d’authentification SSH. Il faudra ensuite déclarer la clé publique dans son profil gitlab/github pour être reconnu par le serveur automatiquement lorsqu’on lui envoie des modifications.

Il faudra ensuite pour chaque projet RStudio indiquer s’il doit être suivi ou non par git.

Pour en savoir plus sur cette étape : lien vers la doc RStudio

1.3 Les fonctionnalités de Gitlab

On peut demander à gitlab de nous parler en français !

ça se passe dans le profil de chacun, au niveau des préférences.

Outre le suivi de version, Gitlab propose également des fonctionnalités de conduite de projet, notamment la gestion de tickets avec les issues : exemple zonages.habitat.r On y retrouve un peu comme sur Trello : des étiquettes, des dates d’échéances, un système d’attribution (@qqun), un lieu d’échanges entre développeurs, clients… le tout, couplé au développement et au versionnage du projet.

Notamment :

  • des notifications par mail à paramétrer selon la fréquence voulue par l’utilisateur selon les projets :
  • des droits à attribuer par projet, par exemple pour que les demandes de fusion soient supervisées ou automatiquement acceptées.

On peut héberger un wiki par projet, en plus du README.md d’accueil.

Gitlab propose aussi et surtout des fonctions d’intégration continues devOps. En gros, à chaque commit, des automates (scripts batch) peuvent contrôler la cohérence de la livraison, réaliser une publication… Ces automates peuvent également être configurés pour se lancer à interval réguliers. Exemple sur {zonages.habitat.r}
Pour en savoir plus : fiche n°4

1.4 Concrétement, comment ça marche ?

1.4.1 Récupérer un projet existant depuis Gitlab vers RStudio (cloner une répertoire gitlab)

Cas le plus simple

1- créer un nouveau projet RStudio
New project / Version control

et connecter ce projet au serveur via l’adresse SSH ou l’adresse HTTP récupérée sur le serveur

2- puis aller dans le terminal ou git shell pour déclarer cette adresse
git remote add origin git@gitlab.com:...
Pour vérifier que le paramétrage est pris en compte git remote -v

3- Déclarer la branche main pour activer les boutons push/pull de Rstudio par
git push -u origin main

4- récupérer le projet par un pull

1.4.2 Initier un projet existant depuis RStudio vers gitlab

Un peu plus galère… Ici exemple d’un projet poussé vers le serveur intranet.

  • D’abord, si ce n’est pas déjà fait, activer le suivi de version pour le projet (menu Tools/Project options/Git-SVN),
    cela active le suivi local par git et crée le répertoire .git le fichier .gitignore à la racine du projet.
  • Il faut alors redémarrer rstudio.
  • Réaliser le premier commit local.
  • créer le projet (complètement vide, même nom que celui du projet RStudio) sur le serveur et récupérer son url (http ou ssh, suivant les cas)
  • puis lancer les instructions en lignes de commande
git remote rename origin old-origin
git remote add origin https://gitlab-forge.din.developpement-durable.gouv.fr/dreal-pdl/csd/geodata4apps.fiches.git
git push -u origin --all
git push -u origin --tags

tuto en anglais

1.4.3 Travailler avec Git, Rstudio et Gitlab sur un projet

1.4.3.1 Les commandes de base

Les commandes commit/reverse permettent versionnage local.
Les commandes push/pull/fetch permettent les échanges avec le serveur distant (gitlab).
Elles sont en interface clic-bouton dans RStudio.

La commande merge (fusion) est lancée de manière invisible, en même temps que push ou pull. Si elle échoue parce que des modifications ont été effectuées parallèlement sur le même fichier, les fichiers à problème sont ouverts par RStudio, les conflits sont pointées avec >>>>>>>> HEAD et l’utilisateur doit choisir à la main quelles modifications conserver.

1.4.3.2 Exclure des fichiers du suivi de git

Le fichier .gitignore est un petit fichier .txt situé à la racine du projet. Il permet d’écarter certains fichiers du ‘trackage’ git. Pour des questions de volumétrie et de longueur des traitements, il est conseillé d’éviter de versionner les fichiers de données.

Voici un exemple de fichier .gitignore :
.Rproj.user
.Rhistory
.RData
.Ruserdata
.Rproj.user
.Rhistory
.RData
.Ruserdata
**archives**
**telechargmt**
*.Rproj
**.html
.Rproj.user/*
**.RData
**.csv
**.ods
**.xls*

1.4.3.3 Notion de branches

Les branches permettent de disposer à tout instant de plusieurs versions du même projet. C’est utile par exemple pour :

  • disposer à tout moment d’une version stable et d’une version de de production,
  • travailler à plusieurs sur des axes de développement différents.

Un exemple de branches mal gérées :