Séance 07 - Git le retour

— Version imprimable

Support de présentation (ouvrir en grand) :

Utilisez les flèches ← et → pour naviguer entre les diapositives.

Sommaire

Plan de la séance #

  1. Les principes de Git
  2. Configurer Git
  3. Retour sur les commandes usuelles
  4. Conflits, forks et rebase

Revenons sur Git après une séance de découverte lors de la première saison. Pourquoi s’évertuer à utiliser absolument Git ? Réponse en quelques principes théoriques et avec des manipulations !

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 !

2. Configurer Git #

  • configuration générale : fonctionnement de Git pour tous les projets
  • configuration particulière : pour un projet
  • clés SSH ?…

2. Configurer Git #

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. Configurer Git #

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. Configurer Git #

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 #

  1. créer un dossier : mkdir bac-a-sable
  2. aller dans ce dossier : cd bac-a-sable
  3. créer un fichier : echo "Mon texte" >fichier-01.txt
  4. ajouter le fichier dans l’index et commiter
  5. 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 :

  1. créer une nouvelle branche appelée modifs : git checkout -b modifs
  2. vous êtes désormais sur cette nouvelle branche
  3. modifier le fichier, par exemple : echo "Autre texte hop là" >fichier-01.txt
  4. enregistrer vos modifications dans Git : git commit -a -m "révision de la première ligne"
  5. retourner sur la branche principale : git checkout master (ou git checkout main selon votre configuration)
  6. effectuer une nouvelle modification : echo "Ceci est mon texte" >fichier-01.txt
  7. enregistrer vos modifications : git commit -a -m "réécriture"
  8. 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 un éditeur de texte comme Atom ou VSCode, des options vont vous être proposées : quelle version vous souhaitez choisir ;
  • dans des éditeurs de texte comme Vim, Nano ou autre, vous devez supprimer ce que vous ne voulez pas retenir :
    • les <<<<<<, les ====== et les >>>>>>, ainsi que les mentions des commits et de HEAD
      • c’est à vous de conserver manuellement ce qui vous intéresse
  • une fois ces modifications faites, vous devez enregistrer le fichier, et commiter tout cela ;
  • effectuer un git status pour s’assurer que tout est en ordre !

4. Conflits, forks et rebase #

forks : comment maintenir sa version à jour ? #

  1. créer un fork du projet sur votre GitLab Huma-Num
  2. cloner le dépôt sur votre ordinateur (dans un autre dossier que le projet précédent)
  3. ajouter l’indication du fork en local : git remote add upstream git@gitlab.huma-num.fr:antoinefauchie/bac-a-sable-2.git
  4. 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.