Introduction à GIT§

Ce travail est sous licence Creative Commons Attribution-ShareAlike 3.0 France.

Motivations§

Exemple 1§

Exemple 2§

Histoires vraies§

• Après que nous avons échangé avec un collègue des versions d'un fichier nommées X_1.1.doc, X_1.2.doc, X_1.3.doc (et ainsi de suite),

  il a nommé la version finale X_1.0.doc ...

• Un autre collègue m'a envoyé, le 15 mars 2013, un fichier nommé 2013-03-17-xxx .

  Je l'ai modifié le 16 mars ; quel nom lui donner ?...

Conclusion§

• La gestion des versions est un travail fastidieux et méthodique.
• Les humains ne sont pas doués pour les travaux fastidieux et méthodiques.
• Laissons cela à l'ordinateur,
  • et concentrons-nous sur la partie du travail où nous sommes meilleurs que l'ordinateur.

→ VCS (Version Control System)

Avertissement§

• GIT (se prononce « guite ») est un outil extrêmement riche ;
  • nous n'en verrons qu'une partie dans ce module.
• Ne vous laissez pas effrayer par l'interface « touffue » ;
  • faites confiances aux réglages par défaut (dans un premier temps).

Historique des VCS§

Origines§

• Initialement dédiés à la gestion de code source pour les projets logiciels
• mais également :
  • documentation
  • site web
• travail collaboratif :
  • facilité d'échange
  • traçabilité
  • gestion des conflits

Évolutions§

Systèmes centralisés

• CVS (Concurrent Versioning System, vieillissant)
• SVN (Subversion, très populaire, mais c'est en train de changer)

Systèmes décentralisés

• GIT
• Mercurial (Hg)
• Bazaar (bzr)

→ facilitent une utilisation individuelle

Notions de base§

Bon exemple§

Les avantages de la gestion de versions§

• Sauvegarde (modulo la synchronisation avec un serveur distant)
• Conservation de l'historique (nominatif) des fichiers (qui a fait quoi ?)
• Possibilité de retour en arrière
• Fusion des modifications lors du travail collaboratif
• Visualiser les changements au cours du temps

Notions§

Dépôt (repository)§

Le répertoire caché .git est nommé dépôt (en anglais repository).

Il contient toutes les données dont GIT a besoin pour gérer l'historique. Sauf rarissimes exceptions, vous ne modifierez jamais son contenu directement, mais uniquement en passant par les commandes GIT.

Commit§

L'historique d'un projet est une séquence de « photos », contenant l'état de tous les fichiers du projet.

Ces « photos » s'appellent des commits, et possèdent :

• une date
• un auteur
• une description textuelle
• un lien vers le(s) commit(s) précédent(s)

On parle également de révision.

Illustration§

Visualisation d'un historique simple dans un outil graphique.

NB : on ignore pour l'instant le rectangle master ; on l'expliquera par la suite.

Remarque§

Bien que conceptuellement, chaque commit contient tous les fichiers du projet, GIT utilise un système de stockage très efficace :

• le commit ne stocke que les fichiers modifiés par rapport au commit précédent;
• l'ensemble peut être compressé (git gc) pour réduire encore la redondance (lorsque deux versions successives d'un fichier sont très proches).

NB : bien que GIT (et les autres VCS) soient plus particulièrement conçus pour des fichiers texte, ils fonctionnent aussi avec des fichiers binaires (images, bureautique, etc.).

Copie de travail§

On appelle copie de travail (en anglais working copy) les fichiers effectivement présents dans le répertoire géré par GIT.

Leur état peut être différent du dernier commit de l'historique.

Index§

L'index est un espace temporaire contenant les modifications prêtes à être « commitées ».

Ces modifications peuvent être :

• création de fichier
• modification de fichier
• suppression de fichier

Mise en œuvre§

Dans ce cours, nous considérerons deux méthodes possibles :

• Ligne de commande (Git Bash)
• Interface graphique (TortoiseGit)

Création du dépôt§

Initialise la gestion de version dans un répertoire en créant le sous-répertoire .git.

Mise en œuvre

• Dans le menu contextuel du répertoire concerné, Git Create repository here...

• En ligne de commande, depuis le répertoire concerné:

  $ git init
  

Commiter des modifications§

Une fois les fichiers modifiés et dans un état satisfaisant, vous pouvez les commiter.

Remarque : lorsque vous effectuez un commit, il est essentiel d'écrire un message accompagnant le commit. Ce message doit être informatif quant à la nature des modifications que vous êtes en train de commiter.

Par exemple, blip est un mauvais message de commit, mais Correction des fautes d'orthographe dans la doc technique est un bon message de commit.

Depuis l'interface graphique§

En ligne de commande§

Ajouter un fichier dans l'index

$ git add <filename>

Retirer un fichier de l'index

$ git reset <filename>

Pour voir l'état des modifications en cours

$ git status    # résumé
$ git diff      # détail des changements

Pour commiter les modifications indexées

$ git commit    #ou
$ git commit -m "message de commit"

Consulter l'historique§

• Menu contextuel > TortoiseGit > Show log

  (cf. figure suivante)

• En ligne de commande :

  • afficher la liste des commits

    $ git log
    

    (avec l'identifiant de chaque commit)

  • afficher le détail d'un commit particulier

    $ git show <id-commit>
    

Depuis l'interface graphique§

Résumé des états possibles d'un fichier avec GIT§

Figure inspirée de git-scm.org.

Naviguer dans l'historique§

Motivation§

L'intérêt d'utiliser un VCS est de pouvoir consulter n'importe quelle version antérieure du projet.

⚠ Attention cependant :

• à ne pas avoir de modification non commitée lorsque vous commencez à naviguer dans l'historique ;
• à ne pas faire de modification sur une version ancienne.

Dans les deux cas, vous risqueriez de perdre ces modifications (GIT affiche d'ailleurs des messages d'avertissement).

Mise en œuvre§

• Menu contextuel > TortoiseGit > Switch/Checkout...

  • cocher Commit,
  • saisir une Expression de révision (cf. ci-après),
  • le cas échéant, décocher Create New Branch,
  • valider.

• En ligne de commande :

  $ git checkout <revision>
  

Expressions de révision§

Il existe plusieurs méthodes pour spécifier une révision à GIT :

(liste non exhaustive)

Identifiant§

Chaque commit a un identifiant, affiché

• par l'interface graphique (cf. figure),
• par la commande git log.

On peut spécifier une révision en utilisant

• l'identifiant complet du commit, ou
• les premiers caractères de l'identifiant, tant qu'il n'y a pas d'ambiguïté

Exemple :

$ git checkout 9a063f5fd514e966837163ceffaec332ce66fdff    # ou
$ git checkout 9a063

Relatif§

HEAD~ ou HEAD~1 désignent le parent du commit courant. Ainsi :

$ git checkout HEAD~

permet de remonter d'un commit dans l'historique.

NB : HEAD~2 remonte de deux commits, HEAD~3 de trois commits, et ainsi de suite.

Retour au présent§

• Menu contextuel > TortoiseGit > Switch/Checkout...

  • s'assurer que Branch est bien coché,
  • s'assurer que master est bien sélectionné dans la liste correspondante,
  • valider.

• En ligne de commande :

  $ git checkout master
  

NB : ceci est en fait un cas particulier de l'action Changer de branche que nous étudierons un peu plus tard.

Entractes§

Nous venons de voir les fonctionnalités les plus basiques de GIT, qui permettent de gérer efficacement correctement l'historique d'un ensemble de fichiers → à utiliser sans modération.

Dans la suite, nous allons étudier des fonctionnalités un peu plus avancées, qui seraient impraticables avec une gestion « manuelle » de l'historique.

• elle peuvent donc vous sembler superflues,
• mais s'avèrent vite indispensables quand on y a pris goût.

Branches§

Motivation§

Dans certaines situations, on peut souhaiter faire cohabiter et évoluer plusieurs versions divergentes du même projet.

Ces versions peuvent parfois converger à nouveau (mais pas forcément).

Exemple 1 : CV§

Pour un CV, on souhaite avoir :

• une version « maître » que l'on maintient à jour,
• des variantes pour chaque demande d'emploi, adaptées en fonction de l'employeur visé.

Illustration§

Exemple 2 : site web§

Pour un site web, on souhaite avoir :

• la version publiée,
• une version de travail, dans laquelle on apporte des modifications incrémentales.

Les deux versions mènent leur existence en parallèle, la version publiée étant régulièrement mise à jour par rapport à la version de travail.

Illustration§

Exemple 3 : logiciel§

Dans un projet logiciel, on souhaite avoir :

• la version stable, dans laquelle on se contente de corriger des bugs, et
• une ou plusieurs versions expérimentales, dans lesquelles on implémente de nouvelles fonctionnalités ;

Une fois au point, chaque nouvelle fonctionnalités est intégrée à la version stable.

Illustration§

Notions§

• Une branche est la lignée (généalogique) de commits, à laquelle on a donné un nom.
• Le commit le plus récent de la branche est appelé sommet (en anglais tip) de cette branche.
• La copie de travail est (en général) liée au sommet d'une branche (master par défaut).
• À chaque nouveau commit, le sommet de la branche courante est avancé vers ce nouveau commit (la branche « pousse »).

Accessibilité§

Un commit est accessible s'il appartient à au moins une branche. Les commits non accessibles sont automatiquement supprimés par GIT.

Lorsqu'on navigue dans l'historique, on lie la copie de travail à un commit particulier plutôt qu'à une branche (mode detached HEAD).

→ Les commits que l'on ferait dans cet état n'appartiendraient à aucune branche et seraient donc perdus.

Mise en œuvre§

Afficher la liste des branches§

• Dans les interfaces graphiques :

  elle apparaît chaque fois qu'elle est nécessaire

  (par exemple, dans la boite de dialogue Switch/Checkout... vue précédemment).

• En ligne de commande :

  $ git branch
  

  Le nom de la branche courante apparaît précédé d'une étoile.

Créer une nouvelle branche§

Cette opération consiste à placer, sur un commit existant, le sommet d'une nouvelle branche (qui pourra croître indépendamment des autres).

Depuis l'interface graphique§

Menu contextuel > TortoiseGit > Create Branch...

• on doit choisir un nom pour la nouvelle branche ;
• dans la section « Base on », on peut choisir sur quel commit la nouvelle sera créée (par défaut: commit courrant HEAD) ;
• si on coche la case Switch to new branch (en bas à droite) la nouvelle branche deviendra la branche courante.

En ligne de commande§

Pour créer une nouvelle branche sur le commit courant :

$ git branch <nom_nouvelle_branche>

Pour créer une nouvelle branche à un autre emplacement :

$ git branch <nom_nouvelle_branche> <revision>

Ces commandes ne changent pas la branche courante. Pour créer une nouvelle branche et en faire la branche courante, utilisez plutôt :

$ git checkout -b <nom_nouvelle_branche>    # ou
$ git checkout -b <nom_nouvelle_branche> <revision>

Changer de branche§

Cette opération consiste à modifier la copie de travail pour la mettre dans le même état que le sommet d'une branche.

Mise en œuvre§

• Menu contextuel > TortoiseGit > Switch/Checkout...

  • s'assurer que Branch est bien coché,
  • sélectionner dans la liste correspondante le nom de la branche,
  • valider.

• En ligne de commande :

  $ git checkout <branche>
  

À propos de git checkout§

La commande git checkout est utilisée dans divers contextes, qui rendent difficile à percevoir sa cohérence interne.

La fonction première de cette commande est de modifier l'état de la copie de travail. Selon ses arguments, elle a des effets supplémentaires :

• un branche : changer la branche courante
• une révision : passer en mode detached HEAD

Fusionner deux branches§

L'opération de fusion (en anglais merge) permet d'intégrer les modifications d'une branche dans une autre.

Il y a deux situations possibles, selon les positions relatives de la branche à fusionner (source) et de la branche destination.

Fusion sans commit§

Si la branche destination est contenue dans la branche source,

la fusion a simplement pour effet de déplacer le sommet de la branche cible.

Ce type de fusion est appelée fast forward.

Note

Ce comportement préserve autant que possible un historique linéaire, donc plus simple.

Cependant, dans certains cas, on souhaite forcer la création d'un commit même lorsqu'on est dans cette situation (c'est notamment le choix qui a été fait dans l'exemple du site web).

Pour cela, en ligne de commande, on ajoutera l'option --no-ff.

Avantage : les deux branches gardent leur identité dans le graphe.

Fusion avec commit§

Si la branche destination et la source ont divergé,

la fusion crée un nouveau commit intégrant les modifications des deux branches ;

ce commit devient le sommet de la branche destination.

Mise en œuvre§

• Menu contextuel > TortoiseGit > Merge...

  • s'assurer que Branch est bien coché,
  • sélectionner la branche à fusionner dans la branche actuelle,
  • valider.

• En ligne de commande :

  $ git merge <branche>
  

Gérer les conflits§

Motivation§

La fusion de branches est automatiquement gérée par GIT lorsque les modifications des deux branches portent sur :

• des fichiers différents, ou
• des parties distinctes des mêmes fichiers texte.

Exemple géré par GIT§

Branche 1 :

- La première ligne
+ La première ligne modifiée
La deuxième ligne
La troisième ligne

Branche 2 :

La première ligne
La deuxième ligne
- La troisième ligne
+ La troisième ligne modifiée

Fusion :

La première ligne modifiée
La deuxième ligne
La troisième ligne modifiée

Exemple non géré par GIT§

Branche 1 :

- La première ligne
+ La première ligne modifiée
La deuxième ligne
- La troisième ligne
+ La troisième ligne modifiée

Branche 2 :

- La première ligne
+ La première ligne changée
La deuxième ligne
La troisième ligne

Conflit§

On a donc un conflit lorsque les deux branches modifient :

• un même fichier binaire, ou
• la même partie d'un fichier texte.

Dans ce cas, le conflit doit être résolu à la main avant de pouvoir créer le commit de fusion.

Remarque§

Mise en œuvre§

Lorsque GIT rencontre un conflit au moment d'une fusion, un message indique les fichiers en conflit.

On est dans un état instable qui suppose :

• de résoudre le conflit, ou
• d'abandonner la fusion.

Fichiers comportant un conflit§

Les fichiers texte comportant un conflit sont automatiquement modifiés pour :

• inclure les modifications non conflictuelles, et
• faire apparaître les deux versions concurrentes pour les modifications conflictuelles.

<<<<<<< HEAD
La 1e ligne modifiée
=======
La 1e ligne changée
>>>>>>> src
La 2e ligne
La 3e ligne modifiée

Les fichiers binaires ne sont pas modifiés.

Résolution du conflit§

Une fois les fichiers en conflit corrigés, on peut résoudre le conflit :

• Menu contextuel > TortoiseGit > Resolve...

• En ligne de commande :

  $ git commit -a
  

Le nouveau commit aura pour parents les sommets des branches fusionnées.

Abandon§

On peut également décider d'abandonner la fusion :

• Menu contextuel > TortoiseGit > Abort Merge

• En ligne de commande :

  $ git merge --abort
  

Dépot distant§

Notion§

Un dépôt distant (en anglais remote repository) est un dépôt GIT, tout à fait similaire à un dépôt local, mais acessible à distance via une URL.

Exemple : https://github.com/pchampin/intro-git.git

Un dépôt local peut être lié à un dépôt distant ; GIT offre des fonctionnalités pour copier des commits de l'un à l'autre.

Motivations§

• sauvegarder le projet (fichiers + historique),
• travailler sur plusieurs machines,
• rendre le projet accessible à d'autres personnes,
• travailler sur un projet publié par quelqu'un d'autre,
• collaborer à plusieurs sur un projet (ce sera l'objet du chapitre suivant).

Vue d'ensemble§

Mise en œuvre§

Créer un dépôt sur un serveur§

Il existe plusieurs sites permettant d'héberger et de partager vos projets GIT :

dont un hébergé par l'université Lyon 1 :

http://forge.univ-lyon1.fr/

Cloner un dépôt distant§

Une fois votre dépôt distant créé, vous pouvez en faire un clone (une copie à la fois des fichiers et de l'historique) sous forme d'un dépôt local, qui sera lié à ce dépôt distant.

Mise en œuvre

• Menu contextuel > Git Clone...

  • dans le champs URL, sélectionner l'URL du dépôt distant ;
  • le cas échéant, modifier l'emplacement du dépôt local ;
  • valider.

• en ligne de commande :

  $ git clone <url-dépôt-distant> <emplacement>
  

Problème depuis le campus Lyon1§

Si vous rencontrez des problèmes pour cloner un dépôt, cela peut venir d'une mauvaise configuration du proxy. Dans Git Bash, tapez les deux commandes suivantes :

$ git config --global http.proxy http://proxy.univ-lyon1.fr:3128
$ git config --global https.proxy https://proxy.univ-lyon1.fr:3128

puis tentez à nouveau.

Publier des commits§

Cette opération copie sur le dépôt distant les commits locaux (de la branche courante) qui n'y sont pas encore présents.

Mise en œuvre

• Menu contextuel > TortoiseGit > Push...

• En ligne de commande :

  $ git push
  

Désynchronisation§

Le push n'est possible que si la branche locale contient tous les commits présents dans la branche distante (plus, bien sûr, les nouveaux commits que vous voulez pousser).

Si la branche distante contient des commits inconnus de votre dépôt local (poussés depuis une autre machine, par vous ou quelqu'un d'autre), il faudra au préalable les récupérer (cf. ci-après).

Récupérer les commits§

Cette opération copie dans le dépôt local les commits distants (de la branche courante) qui n'y sont pas encore présents. Elle met également à jour la copie de travail.

Cela est nécessaire

• lorsque vous travaillez sur plusieurs machines, et utilisez le dépôt distant pour les synchroniser, ou
• lorsque le dépôt distant est modifié par quelqu'un d'autre.

Mise en œuvre

• Menu contextuel > TortoiseGit > Pull...

• En ligne de commande :

  $ git pull
  

Désynchronisation§

Dans le cas le plus simple, le dépôt distant est « en avance » par rapport au dépôt local : il contient tous les commits du dépôt local, plus ceux que vous cherchez à récupérer.

Dans un cas plus complexe, des commits ont pû être ajoutés parallèlement dans les deux dépôts. Dans ce cas, pull effectue automatiquement une opération de fusion. Cela peut entraîner un conflit, qu'il faudra résoudre comme vu précédemment.

Collaboration§

Motivation§

• On a vu que GIT gérait l'évolution des fichiers, qu'elle soit linéaire ou non linéaire (branches) :
  • en facilitant la fusion des modifications parallèles, et
  • en détectant les conflits.
• Déjà utiles dans un contexte individuel, ces fonctionnalités vont s'avérer primordiales dans un contexte collectif.

Notions§

• Lorsqu'on travaille à plusieurs,
  • chacun possède une copie des fichiers.
• Lorsqu'on travaille à plusieurs avec GIT,
  • chacun possède une copie des fichiers et du dépôt.
• On ne s'échange plus les fichiers individuellement,
  • mais des commits (donc des états cohérents de l'ensemble des fichiers).
• On met en commun en fusionnant les branches.

Dépôt distant§

On a vu dans la section précédente qu'un dépôt local pouvait être lié à un dépôt distant.

En fait, un dépôt GIT peut être lié à un nombre arbitraire de dépôts distants, chacun identifié par un nom.

Lors d'un clone, le dépôt cloné est automatiquement ajouté comme dépôt distant, sous le nom origin.

Branche de suivi§

Pour chaque branche de chaque dépôt distant, GIT crée dans le dépôt local une branche spéciale appelée branche de suivi (en anglais remote-tracking branch). Son nom est de la forme :

<nom-dépôt-distant>/<branche>

Cette branche reflète l'état de la branche distante correspondante ; elle n'est jamais modifiée directement.

Elle peut en revanche être fusionnée à une branche locale, afin d'y intégrer les modifications faites par d'autres.

Mise en œuvre§

Lier à un dépôt distant§

• Menu contextuel > TortoiseGit > Settings > Git > Remotes

  (interface complète de gestion des dépôts distants)

• En ligne de commande :

  $ git remote add <nom> <emplacement>
  

Mettre à jour les branches de suivi§

On a vu précédemment la commande git pull qui récupère les commits distants et les fusionne dans la branche courante.

La commande git fetch permet de simplement récupérer les commits distants et de mettre à jour les branches de suivi, sans impacter les branches locales.

Mise en œuvre§

• Menu contextuel > TortoiseGit > Fetch...

  • s'assurer que Remote est bien coché,
  • sélectionner le dépôt distant souhaité la liste correspondante,
  • valider.

• En ligne de commande :

  $ git fetch <nom-dépôt-distant>
  

Fusionner une branche de suivi§

Le principe est le même que pour la fusion entre branches locales.

• Menu contextuel > TortoiseGit > Merge...

  • s'assurer que Branch est bien coché,
  • sélectionner la branche de suivi à fusionner dans la branche actuelle,
  • valider.

• En ligne de commande :

  $ git merge <branche-de-suivi>
  

Organisation en étoile§

Organisation pair-à-pair§

Organisation "github"§

Ré-écrire l'histoire§

Motivation§

Avant de publier un ensemble de commits, on peut souhaiter le « nettoyer » un peu,

notamment pour rendre l'historique du projet plus lisible.

Amendement§

Il arrive que l'on fasse un commit incomplet :

• oubli d'ajouter certains fichiers / certaines modifications,
• coquilles dans les ajouts...

On peut bien sûr corriger cet oubli dans un nouveau commit, mais cela contredit l'idée qu'un commit représente un état cohérent de l'ensemble des fichiers.

Dans ces situations, il est possible de modifier (amender) le dernier commit créé.

Mise en œuvre§

• Dans la boite de dialogue de commit :

  • cocher le bouton radio Amend last commit

• En ligne de commande :

  $ git commit --amend
  

Rebase§

On a vu que la fusion de deux branches créait un commit à plusieurs parents si les branches avaient divergé.

Si on préfère garder un historique linéaire, GIT permet de « rejouer » les modifications d'une branche à partir du sommet de l'autre branche, en re-créant les commits correspondants.

Mise en œuvre§

• Menu contextuel > TortoiseGit > Rebase...

• En ligne de commande (depuis la branche à « rebaser ») :

  $ git rebase <branche-destination>
  

Pour aller plus loin§

Se documenter§

• Deux tutoriels graphiques et animés ici et là.

• Si vous voulez en savoir plus sur GIT, consultez son excellente documentation sur git-scm.org ainsi que les vidéos très instructives !

Autres outils de gestion de version§

• Vous n'êtes pas certains de préférer GIT? Prenez le temps de comparer les différents outils de gestion de version. Il existe de nombreux comparatifs en ligne, comme par exemple sur Wikipedia.

Mercurial

• Mercurial (abbrégé Hg) est un gestionnaire de version similaire à GIT, mais comporte quelques différences (de terminologie notamment).
• Un guide de pour passer de GIT à Mercurial est disponible ici : https://www.mercurial-scm.org/wiki/GitConcepts

Un dernier conseil§

Rien de tel que la pratique pour maîtriser GIT (ou tout autre outil de gestion de version), alors n'hésitez pas à utiliser abondamment ces outils, même pour vos petits projets...

Crédits§

Ce support a été réalisé par Pierre-Antoine Champin et Amélie Cordier.

Merci à Isabelle Gonçalves et Jocelyn Delalande pour leurs contributions.