Débugue tes humanités Saison 2
Séance 07 - Git le retour
Usage réel, paramètres et configuration, gestion des conflits, merge requests, etc.
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. — antoine.fauchie@umontreal.ca
Plan de la séance #
Les principes de Git
Configurer Git
Retour sur les commandes usuelles
Conflits, forks et rebase
1. Les principes de Git #
suivre un projet
développements/évolutions non linéaires (branches)
historique général et particulier
système de gestion de versions distribué
complexité relative
logiciels/plateformes qui simplifient l’usage
Git est pensé pour versionner un projet , seul·e ou à plusieurs.
Si Git permet de versionner des fichiers, il ne faut pas oublier que l’objectif final est bien de suivre un projet dans son ensemble et pas forcément un fichier en particulier
1. Les principes de Git #
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.
1. Les principes de Git #
À retenir #
Comme beaucoup d’outils, Git nécessite quelques réglages préalables !
configuration générale : fonctionnement de Git pour tous les projets
configuration particulière : pour un projet
clés SSH ?…
2.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 "Antoine Fauchié"
Git repose sur la reconnaissance des personnes qui contribuent ensemble à un même projet, il est donc primordial de bien identifier qui est qui.
Pour cela il faut au moins une adresse électronique, mais avec un nom ou un pseudonyme on gagne en lisibilité.
Il est aussi possible de spécifier beaucoup d’autres paramètres , comme l’éditeur de texte par défaut qui sera utilisé pour les messages des merges par exemple.
2.2. Configuration particulière #
par défaut : configuration générale qui s’applique
a minima : les branches disponibles en local et le dépôt distant
possible de spécifier
Il est par exemple possible de spécifier un utilisateur différent pour chaque dépôt/projet.
Cela peut être pratique pour distinguer des usages professionnels et des usages plus personnels.
2.3. Clés SSH ?… #
3. Retour sur les commandes 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
Pour afficher un historique plus détaillé : git log --decorate=full --raw
Ou pour afficher l’arbre des branches : git log --branches --remotes --tags --graph --oneline --decorate --pretty=format:"%h - %ar - %s"
Le concept de branche est un raccourci bien pratique : cela permet d’identifier des commits facilement, et de créer un
3. Retour sur les commandes usuelles #
Exercice 1 #
créer un dossier : mkdir bac-a-sable
aller dans ce dossier : cd bac-a-sable
créer un fichier : echo "Mon texte" >fichier-01.txt
ajouter le fichier dans l’index et commiter
afficher l’historique
4. Conflits, forks et rebase #
un conflit : il faut choisir
forks : comment maintenir sa version à jour ?
rebase : les bonnes pratiques difficiles à mettre en place
4. Conflits, forks et rebase #
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
4. Conflits, forks et rebase #
Exercice 2 : gestion d’un conflit #
Suite à l’exercice 1, nous allons créer plusieurs modifications :
créer une nouvelle branche appelée modifs
: git checkout -b 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"
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 !
4. Conflits, forks et rebase #
forks : comment maintenir sa version à jour ? #
créer un fork du projet sur votre GitLab Huma-Num
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.huma-num.fr:antoinefauchie/bac-a-sable-2.git
pour récupérer les modifications du dépôt d’origine : git fetch upstream
5 pour synchroniser ces modifications avec votre dépôt : git rebase upstream/master
4. Conflits, forks et rebase #
rebase : les bonnes pratiques difficiles à mettre en place #
Un tutoriel complexe à explorer si vous êtes motivé·e :
https://git-rebase.io
Mais si nous avons le temps nous allons regarder un exemple.