logo telecom ipp

Chapitre 4 : GIT

Git/Gitlab/Github

Git est un outil incontournable pour l’ingénieur, même non informaticien. Que ce soit pour des logiciels ou des documents issus d’une collaboration, Git s’est imposé comme la norme.

Gitlab/Github sont des serveurs Git qui gèrent le stockage, le partage entre utilisateurs, les autorisations d’accès et puis toute une couche d’outils supplémentaires qui complexifient énormément leur interface. La partie de l’interface juste pour faire du Git est “assez” simple.

Il est important de réaliser que si vous êtes bloqués en git pour quelque raison que ce soit, vous devez consacrer du temps à vous débloquer, en demandant de l’aide, en continuant à vous former, car l’impasse sur git n’est pas possible.

Git: Histoire

Git est la version la plus utilisée de logiciel de contrôle de version.

Qu’est-ce que le contrôle de version ? Il s’agit de stocker toutes les versions de tous les fichiers dans un projet, avec pour chaque version, des commentaires, dates et auteur.

GIT: Pourquoi

  • Vous travaillez en groupe et un collègue a tout cassé la dernière version et vous devez faire une démo dans une heure : en un clic, vous revenez à la version précédente qui marche
  • On vient vous voir pour un comportement qui a changé entre la v2 et la v3. Vous en êtes à la v7 et toute l’équipe a changé depuis. Vous reconstruisez la v2. Vous reconstruisez la v3. En comparant les journaux de fonctionnement, vous isolez le fichier fautif, et avec les commentaires de chaque version, vous retrouvez la raison des changements et le défaut de logique.
  • Vous avez travaillé pendant trois mois sur votre machine sans sauvegarde et votre disque crashe la veille du rendu (histoire vraie arrivée à un de mes étudiants).
  • Vous avez travaillé sur un projet seul pendant un an, vous trouvez un bug et vous n’avez aucune idée d’où ça vient. Vous testez les versions par dichotomie et vous trouvez rapidement le commit qui introduit le bug.
  • Même chose sur un projet d’équipe, et là, vous avez le nom de l’auteur du commit et vous pouvez aller lui demander.

Git est le logiciel à la mode, mais il y a eu d’autres logiciels de contrôle de version : CVS, SVN, SourceSafe, ClearCase, Mercurial, etc.

Git: Principe

Contrairement aux logiciels précédents, qui stockaient les différences entre les versions, Git stocke les versions entières. Le dépôt Git est donc un peu plus gros. Il se trouve dans un dossier .git qui est dans le dossier racine du projet. Il ne faut jamais modifier ce dossier .git ou son contenu.

Les éléments de Git sont :

  • Un dossier de travail contenant une version du projet
  • Un dossier .git qui contient le dépôt local avec toutes les versions
  • En général, un dépôt distant hébergé par un serveur du type GitLab

Les opérations courantes sont :

  • Cloner un dépôt distant : récupérer un dépôt local copie d’un dépôt distant, par exemple celui d’un logiciel libre disponible sur github,
  • Initier un dépôt dans le dossier projet pour un projet qui démarre
  • Faire des modifs sur un projet, et créer un commit en local
  • Push : Envoyer un commit local vers un dépôt distant
  • Pull : récupérer des modifs d’un collègue sous la forme de commits contenant des nouvelles versions, et peut être gérer les conflits

GIT: Installation

GIT: Transparents Git 1

GIT UE Outils

Suivent les transparents vus dans la video précédente

  • concept de copie de travail, “stage” et dépôt local (.git)
  • git init: créer un dépôt local
  • git status: quel est l’état du dépôt local
  • git log: voir des infos sur les commits
  • git add: ajouter un fichier à git, ou ajouter des changements au prochain commit
  • git commit: stocker dans git une nouvelle version

Concepts

  • Il y a un dossier projet
  • Dans ce dossier il y a une copie de travail
  • Dans ce dossier, il y a un sous-dossier caché .git (dépôt local)
  • Il y a une liste ou index (ou stage en anglais) contenant les changements prêts à être mis dans le dépôt
  • Git s’applique autant à du logiciel qu’à des documents en texte (ex: latex)
  • Il y a souvent un serveur distant
  • Les systèmes libres/gratuits sont : CVS, puis SVN, maintenant GIT

Utilisation

La boucle de travail de base est:

  1. Changez vos programmes
  2. Ajoutez vos changements à l’index
  3. Commit = créez une copie dans le dépôt GIT avec un message de documentation

En images, fichiers et commits

Dépôt

En anglais: repository.

Ce sont les données du système de contrôle de version, c’est à dire au moins toutes les versions de tous les fichiers (ou un moyen de les reconstituer). C’est aussi toutes les informations d’auteur, de temps, de dépendance, de branches…

Un dépôt GIT peut être assez gros.

  • dépôt local:
    • sur votre machine
    • pour pouvoir travailler sans connexion
    • dans un dossier .git
    • contient toute l’information du projet; vous pouvez recréer un dépôt distant à partir d’un dépôt local
    • ne changez jamais le contenu du dossier .git !!!
  • nous verrons plus tard les dépôts distants

Commit

Un commit décrit une version comme un ensemble de changements sur au moins un fichier. Un commit peut contenir beaucoup de changements sur beaucoup de fichiers, des changements de texte, de permission, de nom, de dossier… Un commit est identifié avec un code de hashage (SHA-1).

Un commit a aussi un message le décrivant, et il est important de mettre un message le plus clair et simple et cohérent possible.

Copie de travail

La copie de travail, c’est une copie de la version courante du dépôt que vous pouvez éditer et modifier. La version courante est celle marquée “HEAD”.

Vous ne pouvez pas changer la version de travail si votre copie de travail est modifiée

Si votre copie de travail est modifiée, c’est à dire différente de la version courante dans git, alors vous pouvez:

  • préparer (stage) vos changements pour le prochain commit puis commit
  • supprimez vos changements et revenir à la version courante dans git
  • stash sauver vos changements dans la pile de stash et revenir à la version courante dans git

Si votre copie de travail n’est pas modifiée, alors vous pouvez:

  • changer la version courante dans la copie de travail
  • récupérer des changements dans la pile de stash

L’état de la copie de travail est affiché par git status

Configuration de base GIT

Pour vous faciliter la vie, faites, dans un terminal:

git config --global core.pager ''
git config --global core.editor nano
git config --global user.name "votre nom"
git config --global user.email "votre@email"

La première ligne concerne git log. git log utilise par défaut un éditeur simplifié nommé “less”, et cela force à taper q pour sortir de l’affichage d’une liste de commits.

La deuxième ligne concerne git commit. Si vous n’utilisez pas l’option -m, alors git commit lance l’antique éditeur de texte vi. nano est un peu plus moderne et facile à utiliser.

Les deux dernières lignes simplifient les messages affichés par commit.

git init

Cette commande crée un dépot local dans le dossier courant.

Si tout va bien, il n’y a pas de message. Tout message signale une erreur et doit être lu.

git status

Cette commande donne des informations sur l’état du dépot git dans le dossier courant:

  • branche courante
  • fichiers modifiés ou non suivis par Git (en rouge)
  • fichiers modifiés dans l’index (en vert)

git add

Cette commande permet d’ajouter un fichier ou tous les fichiers d’un dossier dans l’index.

git add src/tp01/Main.java ajoute src/tp01/Main.java à l’index, c’est à dire au prochain commit.

git add src ajoute tous les fichiers dans le dossier src à l’index.

Si tout va bien, il n’y a pas de message. Tout message signale une erreur et doit être lu.

git commit

Cette commande crée un commit à partir de tous les fichiers placés dans l’index.

git commit crée un commit et ouvre un éditeur de texte pour vous forcer à écrire un message de commit.

git commit -m "message" crée un commit avec le message donné.

Si tout va bien, il n’y a pas de message. Tout message signale une erreur et doit être lu.

git log

Cette commande affiche des informations sur les précédents commits.

git log affiche tous les commits

git log --stat affiche tous les commits y compris les informations sur les fichiers inclus dans chaque commit.

Scenarios d’utilisation courante

Créer un nouveau dépôt :

  • créez un dossier et faites cd dans ce dossier
  • git init
  • créez ou copiez des fichiers dans le dossier
  • git add
  • git commit

Questions de base: comment faire ?

  • créer un dépôt local ? git init
  • savoir si la copie de travail est modifiée ? git status
  • ajouter un nouveau fichier à git ? git add file
  • ajouter des modifications d’un fichier au prochain commit ? git add file
  • voir des infos sur les commits ? git log
  • faire un commit sur des changements ? git commit -m "message"
  • savoir si des changements sont dans le stage ? git status et les fichiers du stage sont en vert

GIT: Exemple Initier un dépôt

GIT: Transparents Dépots distants

GIT: Transparents Dépots distants

Suivent les transparents de la vidéo précédente.

Dépôts distants

Pour échanger avec d’autres personnes/machines, you avez besoin d’accéder à leur dépôt et eux ont besoin d’accéder au vôtre (ou à une copie).

GIT vous permet de transférer tout ou partie d’un dépôt vers un autre dépôt.

Un dépôt Git local peut être connecté à un dépôt distant sur un serveur Git: le serveur distant a une URL d’accès.

Scenario 2

Télécharger un logiciel libre et l’adapter:

  • git clone URL pour créer un dépôt local depuis le dépôt distant dans URL
  • git checkout BRANCH pour mettre dans la copie de travail la branche qui vous concerne
  • faites des changements, testez, git add, git commit
  • git push pour envoyer les changements sur le dépôt distant

Utilisation avancée

La boucle de travail plus large est:

  1. Pull récupérez les changements du dépôt distant (par ex: de vos collègues)
  2. Faites des modifications, testez, commit, etc… (c’est la boucle initiale)
  3. Push envoyez les nouveaux commits dans le dépôt distant

En images, dépôts et actions

Travailler avec les dépôts distants

  • sans un dépôt distant, vous ne pouvez pas échanger d’information par git avec une autre machine/personne
  • un dépôt distant et un dépôt local contiennent la même chose, mais ne sont pas toujours synchronisés
  • si un dépôt a été créé par git init, il n’a pas de “remote”
    • pour ajouter un lien vers un dépôt distant :
      git remote add distant URL
    • pour ajouter un lien entre une branche locale et le dépôt distant:
      git push --set-upstream distant main
  • si un dépôt local est créé par git clone, un lien vers le dépôt distant existe avec le nom “origin”
  • git push envoie l’état de la branche courante vers le premier dépôt distant
  • git push remoteName envoie l’état de la branche courante vers le dépôt distant nommé remoteName
  • git fetch est l’opposé de git push, il recopie l’information de la branche distante dans la branche locale; la copie de travail n’est pas modifiée
  • git pull est la combinaison de git fetch et git merge
    • s’il y a une erreur de connexion, c’est fetch
    • s’il y a une erreur de fusion, c’est merge qui a créé un conflit que vous devez résoudre avant de continuer

Votre première fusion

Prenons un exemple:

public class Toto {
    public Toto() {}
}

Ce fichier est dans la copie de travail chez vous et au travail.

Vous ajoutez un paramètre au constructeur chez vous :

public class Toto {
    public Toto(int i) {}
}

Vous faites commit, puis push, puis vous travaillez sur autre chose pendant une semaine.

Vous êtes maintenant au travail. Vous refaites la même chose, mais un peu différemment:

public class Toto {
    public Toto(int var) {}
}

Première fusion - 2

Vous faites commit et push. GIT répond que votre dépôt local est en retard sur le dépôt distant. Ce retard est du à la modification poussée la semaine dernière. Comme le suggère GIT, vous faites git pull. Conflit!

Voici le contenu de votre fichier:

public class Toto {
<<<<<<< HEAD
    public Toto(int var) {}
=======
    public Toto(int i) {}
>>>>>>> other
}

GIT a reconnu les parties identiques, et vous montre les deux versions des parties différentes.

Pour résoudre les conflits, vous devez:

  • éditer le fichier
  • choisir l’une des deux versions ou un mix des deux
  • sauver le fichier
  • git add et git commit

Fusion

  • Fusionner des fichiers binaires ne fonctionne pas et n’a pas de sens.
  • S’il y a des changements qui concernent des parties différentes du texte, alors git sait fusionner automatiquement.
  • Il y a de bons outils graphiques pour vous assister dans le travail de fusion, utilisez celui qui vous va le mieux. J’aime la vue fusion de smartGit.
  • Il y a une version plus compliquée de merge, rebase, à éviter pour l’instant.

Clone

git clone URL

  • crée un dépôt local
  • copie toutes les données du dépôt distant URL dans le dépôt local
  • enregistre URL comme dépôt distant (remote) de nom ‘origin’
  • fait un checkout de la branche ‘main’ dans la copie de travail

.gitignore

  • par défaut, tous les fichiers de la copie de travail seront suivis par GIT
  • suivre les binaires et les fichiers générés automatiquement n’a pas de sens
  • .gitignore contient le nom des fichiers qui ne doivent pas être suivis par GIT, un par ligne
    • *.class = ne pas suivre les fichiers avec extension .class
    • bin/ = ne pas suivre le dossier bin
    • file.txt = ne pas suivre le fichier file.txt, même si c’est du texte
  • vous pouvez mettre un .gitignore dans n’importe quel sous-dossier de la copie de travail
  • il faut suivre les fichiers .gitignore dans GIT

Recommandations

  • Créez beaucoup de petits commits cohérents
  • Faites commit quand vous vous arrêtez, même si le programme ne marche pas encore
  • Par contre, ne poussez que du code testé qui marche dans un dépôt partagé
  • Si vous avez des problèmes, regardez cette page d’aide

Cette ressource en anglais est une référence, très complète et d’accès ardu: git-scm.org