Débugue tes humanités Saison 3b

Séance 04 - Git

Le versionnement des documents.

Chaire de recherche du Canada sur les écritures numériques, Bibliothèque des lettres et des sciences humaines, Ouvroir d'histoire de l'art et de muséologie numérique. — roch.delannay@umontreal.ca ; giulia.ferretti@umontreal.ca ; louis-olivier.brassard@umontreal.ca

Plan de la séance #

Les principes de Git
Installer et configurer Git
Les commandes les plus usuelles
Un peu plus avancé : conflits, merge, rebase, forks

1. Qu’est-ce que Git ? Trois principes #

Git est un logiciel de gestion de versions décentralisé : il met en place un système distribué de contrôle de versions (Distributed version control system).

Système distribué (Distributed system)
Versionnement
Contrôle

Système distribué : un ensemble de composants indépendants situés sur des machines différentes qui partagent des messages entre eux afin d’atteindre des objectifs communs.
Versionnement : chaque fois qu’on enregistre (commit), ou qu’on sauvegarde l’état de notre projet dans Git, Git prend un instantané de tous les fichiers, en sauvegardant une référence à l’instantané. Git traite donc nos fichiers comme une série d’instantanés dans le temps. Pour être plus efficace, si Git recconaît que certains fichiers n’ont pas changé depuis l’instantané précédent, Git ne les récupère pas à nouveau, mais crée smplement une collation vers le fichier précédent qui a déjà été sauvegardé.
Contrôle : il n’est pas possible d’enregistrer (commit) une modification dans un fichier sans que cette modification soit vérifiée par le système de Git. Il ne peut pas arriver que des information soient perudes ou qu’un fichier soit corrompu sans que Git s’en aperçoive. Le mécanisme utilisé par Git pour mettre en œuvre cette vérification est un hash appelé SHA-1.

1.1. Un système distribué #

Git permet de copier localement (c’est à dire de sauver sur le disque dur de son propre ordinateur) un dépôt contenu sur un serveur tiers.
Possibilité d’avoir plusieurs dépôts distants
On peut ainsi “committer” du contenu, créer des branches et les merger en local.
git push pour ajouter les changement que on a fait en local sur le dépôt à distance.
Décentraliser pour mieux travailler

1.2. Versionner #

mon-fichier-v2-relu-2021-12-09-final-ok-okok.txt

Pour suivre un projet dans son ensemble (et pas forcément un fichier en particulier).

1.3. Versionner : Décentraliser pour mieux travailler #

Plusieurs principes inhérents à une bonne gestion collective de fichiers informatiques :

ne pas centraliser la sauvegarde
cloner facilement = copier le dossier de travail avec l’ensemble de l’historique
travailler hors connexion
créer des versions parallèles d’un projet –>

1.4. Contrôle #

Git est un système de fichiers adressables en fonction de leur contenu.

2. Installation #

Linux : sudo apt install git-all
Mac : git --version
Windows : Téléchargez le logiciel ICI

Pour voir si git est bien installé sur votre machine : git --version

Exercice #

dans un dossier mon-dossier
créer un fichier mon-fichier.md
git init
git status
git add mon-fichier.md
git commit -m "le message d'enregistrement"
git log
(git fetch, git rebase et git push)

3. Créer un projet en utilisant Git #

Examples #

programmes informatiques : https://github.com/gohugoio/hugo/
documentation : https://github.com/jgm/pandoc/tree/master/doc
projets éditoriaux : https://github.com/thegetty/romanmosaics

Quelques définitions #

dépôt : ensemble des fichiers versionnés
commit : enregistrement des changements dans un dépôt
fork : divergence d’un projet, une copie qui va vivre sa propre vie (ou presque)
cloner : copier un projet chez soi pour pouvoir y contribuer
conflit : lorsque l’on tente de réunir voir de fusionner plusieurs versions d’un même projet

Un commit est une série d’informations :

un identifiant
une date
un message
une liste de modifications associées : les fichiers modifiés

Pour comprendre comment fonctionne Git il faut comprendre ce qu’est un commit : ce n’est pas un enregistrement classique, mais l’état du projet tout entier après une série de modifications sur un ou plusieurs fichiers.

Si le fork n’est pas toujours habituel (c’est la création d’une copie d’un projet qui pourra être indépendant de la version d’origine), le fait de cloner un dépôt est beaucoup plus fréquent. La différence entre les deux est aussi une différence de pratique :

en forkant on s’approprie le projet, si besoin on pourra soumettre des modifications à la version originale tout en travaillant sur notre version ;
en clonant le projet je conserve le projet original, mais je risque de perturber les développements.

Pour commencer #

bien configurer Git
Git ≠ GitHub/GitLab
la bible : https://git-scm.com/book/fr/v2
il est presque impossible de supprimer quelque chose

4. Configurer Git #

4.1. Configuration générale #

basique : un nom et une adresse
avancée : éditeur par défaut, branche par défaut
voir la configuration : git config --list
modifier la configuration, exemple : git config --global user.name "Prénom Nom" ; git config --global user.email "mon.addresse@umontreal.ca"

4. Configurer Git #

4.2. Configuration particulière #

4. Configurer Git #

4.3. Clés SSH #

Secure Socket Shell
Protocole de cryptage
Pour faire interagir mon ordinateur (client) avec un serveur en sécurité
Une clé privée et une clé publique Source
N.B. : Nous nous concentrons sur SSH, mais Git peut en réalité utiliser quatre protocoles distincts pour transférer des données :
- Local
- HTTP
- Secure Shell (SSH)
- Git

5. Comment installer une clé SSH #

Plusieurs algorithmes pour générer une clé SSH.
- Ces algorithmes correspondent à différents modèles de cryptage de la clé.
RSA et ed25519 sont les algorithmes les plus utilisés pour générer des clés SSH.
Une clé publique (qui doit être chargé sur mon ordinateur) et une clé privée (qui reste en local)
command pour générer une clé avec algorithm ed25519 : ssh-keygen -t ed25519 -C "email@exemple.com"
command pour générer une clé avec l’algorithme RSA : ssh-keygen -t rsa -b 4096 -C "email@exemple.com"
-t pour spécifier l’algorithme à utiliser
-b pour spécifier la longer (bits) de la clé
-C pour ajouter un commentaire Source

6. Les commandes les plus usuelles #

git init : initialiser un dossier
git status : voir l’état du projet
git log : afficher l’historique de la branche actuelle
git add : ajouter un fichier dans l’index avant de commiter
git commit : déclarer des modifications
git branch : créer une nouvelle branche
git checkout : pour basculer sur une branche
git push : envoyer les modifications sur un dépôt distant
git fetch : récupérer les modifications d’un dépôt distant
git pull : récupérer les modifications d’un dépôt distant et les fusionner avec le dépôt local

6.1. Encore des fonctionnalités Git #

6.2. Exercice #

créer un dossier : mkdir mon-git
aller dans ce dossier : cd mon-git
git init
créer un fichier : echo "Mon texte" >fichier-01.txt
sauvegarder les changements dans Git
afficher l’historique

7. Conflits, merge, rebase, forks #

un conflit : il faut choisir
forks : comment maintenir sa version à jour ?
rebase : les bonnes pratiques difficiles à mettre en place

7. Conflits, merge, rebase, forks #

7.1. Un conflit : choisir/arbitrer #

pour distinguer les portions : des signes typographiques sont utilisés
certains éditeurs de texte facilitent la visualisation des conflits
si le conflit n’est pas résolu : impossible de continuer

7. Conflits, merge, rebase, forks #

7.2. Exercice : gestion d’un conflit #

Suite à l’exercice 1, nous allons créer plusieurs modifications :

créer une nouvelle branche appelée modifs : git branch modifs et puis git checkout modifs
vous êtes désormais sur cette nouvelle branche
modifier le fichier, par exemple : echo "Autre texte hop là" >fichier-01.txt
enregistrer vos modifications dans Git : git commit -a -m "révision de la première ligne"

7. Conflits, merge, rebase, forks #

7.3. Exercice pt 2 : gestion d’un conflit #

retourner sur la branche principale : git checkout master (ou git checkout main selon votre configuration)
effectuer une nouvelle modification : echo "Ceci est mon texte" >fichier-01.txt
enregistrer vos modifications : git commit -a -m "réécriture"
tenter de fusionner les deux branches : git merge modifs

Vous devez avoir un conflit !

Vous devez ouvrir le fichier pour résoudre le conflit :

dans des éditeurs de texte comme Vim, Nano ou autre, Git ajoute des indications :
- les <<<<<<, les ====== et les >>>>>>, ainsi que les mentions des commits et de HEAD
  - c’est à vous de conserver manuellement ce qui vous intéresse
dans un éditeur de texte plus sophistiqué comme VSCode/VSCodium, des options vont vous être proposées pour choisir la version souhaitée (taper code nom-du-fichier.md sur terminal pour ouvrir VSCode en cas de conflit) ;
vous pouvez également utiliser des logiciels appelées “gitmerge tools”, notamment meld (pour Linux : sudo apt install meld et git config --global merge.tool meld, puis git meld en cas de conflits)
une fois ces modifications faites, vous devez enregistrer (git add) le fichier, et commiter tout cela ;
si vous arrivez pas à résoudre les conflits et vous voulez retourner à la situation précédente : git merge --abort
si vous volez annuler plusieurs commits : git reset --hard hash-du-commit-que-je-veux-sauvegarder
effectuer un git status pour s’assurer que tout est en ordre !

7. Conflits, merge, rebase, forks #

7.4. Git merge #

Source

7. Conflits, merge, rebase, forks #

7.5. Git rebase #

Source

7. Conflits, merge, rebase, forks #

git checkout -b modifs pour se positionner sur une nouvelle branche secondaire
ajoutez et commitez deux fichiers sur cette branche
git checkout master
ajoutez et commitez un fichier sur cette branche
git checkout modifs
git rebase master : les commits dans la branche modifs sont positionnés à la suite des commits de la branche master
git checkout master
git rebase feature : les commits en plus dans ma branche modifs sont désormais ajoutez dans la branche master

7. Conflits, merge, rebase, forks #

7.6. forks : comment maintenir sa version à jour ? #

créer un fork du projet sur votre GitHub
cloner le dépôt sur votre ordinateur (dans un autre dossier que le projet précédent)
ajouter l’indication du fork en local : git remote add upstream git@gitlab.chemin-du/projet
pour récupérer les modifications du dépôt d’origine : git fetch upstream
pour synchroniser ces modifications avec votre dépôt : git rebase upstream/master

7. Conflits, merge, rebase, forks #

7.1. Rebase : les bonnes pratiques difficiles à mettre en place #

Un tutoriel complexe à explorer si vous êtes motivé·e :

https://git-rebase.io

8. Les hosts d logiciels Git (GitLab / GitHab / FramaGit) #

Créez un compte GitHub
Accédez au dépôt ‘debugue-un-test’.
Explorez l’interface : Qu’observez-vous de différent par rapport aux propriétés du logiciel Git ? Qu’est-ce qui est similaire ?
Essayez d’ajouter / de modifier les documents présents : attention aux conflits !