« Gestion de versions » : différence entre les versions

De EduTech Wiki
Aller à la navigation Aller à la recherche
Ligne 121 : Ligne 121 :
Imaginez par exemple un jeu à plusieurs niveaux. Les premiers 2 niveaux ont déjà été développé (le tronc commun). À ce moment, dans l'équipe il n'y a pas d'accord sur comment poursuivre le troisième niveaux : deux idées différentes sont suggérées. Le responsable du  jeu ne veut pas décider avant de voir à quoi ressemblent les niveaux et donc décident de poursuivre le développement deux deux versions du niveau 3, en créant donc deux ''branches'' parallèles. Une fois les deux versions du niveaux 3 développées, le responsable pourra décider laquelle utiliser, en l'incorporant dans la ''voie principale''. L'autre version représente à ce moment un ''dead end'', c'est-à-dire une ''branche'' qui ne sera plus poursuite. Le processus est représenté dans l'image ci bas.
Imaginez par exemple un jeu à plusieurs niveaux. Les premiers 2 niveaux ont déjà été développé (le tronc commun). À ce moment, dans l'équipe il n'y a pas d'accord sur comment poursuivre le troisième niveaux : deux idées différentes sont suggérées. Le responsable du  jeu ne veut pas décider avant de voir à quoi ressemblent les niveaux et donc décident de poursuivre le développement deux deux versions du niveau 3, en créant donc deux ''branches'' parallèles. Une fois les deux versions du niveaux 3 développées, le responsable pourra décider laquelle utiliser, en l'incorporant dans la ''voie principale''. L'autre version représente à ce moment un ''dead end'', c'est-à-dire une ''branche'' qui ne sera plus poursuite. Le processus est représenté dans l'image ci bas.


[[Fichier:Gestion de versions poursuivre alternatives.png|600px|vignette|néant|Poursuivre des alternatives à travers des ''bifurcation'']]
[[Fichier:Gestion de versions poursuivre alternatives.png|600px|vignette|néant|Poursuivre des alternatives à travers des ''bifurcations'']]


Un autre avantage collatérale de la gestion de versions implique que le niveau non retenu va continuer à exister dans les versions précédentes. Il pourrait à ce moment être repris dans un deuxième temps et intégré par exemple en tant que niveau 4 ou 5.
Un autre avantage collatérale de la gestion de versions implique que le niveau non retenu va continuer à exister dans les versions précédentes. Il pourrait à ce moment être repris dans un deuxième temps et intégré par exemple en tant que niveau 4 ou 5.

Version du 22 avril 2020 à 10:01

Cet article est en construction: un auteur est en train de le modifier.

En principe, le ou les auteurs en question devraient bientôt présenter une meilleure version.



Introduction

La gestion de versions - également appelé historique de versions ou contrôle de versions, depuis l'anglais version control system (VCS) - se réfère, dans le milieu numérique, au stockage de plusieurs versions d'un ou plusieurs fichiers afin de pouvoir tracer l'évolution chronologique à travers les changements apportés entre une version et l'autre. La gestion de versions peut s'appliquer à un fichier individuel, comme par exemple dans un document de texte, ou à plusieurs milliers de fichiers qui font partie du même projet. Elle peut s'adopter au niveau individuel ou dans des groupes de travail. La gestion de versions est originairement utilisée surtout dans le milieu de la programmation et du développement informatique, mais elle s'utilise désormais de plus en plus aussi dans des contextes différents, comme par exemple l'écriture collaborative, le Data Science, la recherche, la conception et fabrication assistées par ordinateur, ou encore les processus de conception itératifs comme l'approche centrée utilisateur. La gestion de versions est également souvent à la base de plateformes collaboratives privées ou open source, comme par exemple GitHub ou GitLab.

Dans cet article, nous proposons un aperçu du fonctionnement de la gestion de versions surtout d'un point de vue conceptuel. Pour cette raison, nous incluons également des systèmes de gestion de versions plus simples comme le traçage des changements dans un document de texte ou l'historique des versions dans une page Wiki. Des systèmes de gestions plus complexes, comme par exemple Git, sont en effet une extension de principes de base relativement simple à comprendre, mais plus difficiles à implémenter et à maîtriser.

Objectifs

L'article à deux objectifs principaux :

  1. Introduire le concept de gestion de versions et sensibiliser des personnes sans un background informatique aux avantages d'adopter un mécanisme de ce type dans ses propres fluxes de travail ;
  2. Illustrer quelques exemples de gestion de versions et de logiciels qui peuvent être utilisés pour les implémenter.

Pour comprendre et maîtriser la gestion de versions, cependant, il est nécessaire de la mettre en oeuvre. Cet article vise donc fournir en principe des éléments conceptuels qui puissent être utils dans une perspective d'amorçage, mais qui doivent être ensuite consolidés par la pratique. À ce propos, des exemples de systèmes de gestion de versions sont fourni dans l'article, avec des liens à d'autres articles ou ressources externes plus approfondies.

Prérequis

Aucun prérequis technique n'est nécessaire pour suivre le contenu de l'article.

Pensée computationnelle en sciences sociales

Cet article partage la perspective et le public cible des ressources à propos de la pensée computationnelle en sciences sociales, mais peut être lu de manière indépendante des parcours guidés proposés dans ce contexte.

Principes conceptuels de la gestion de versions

Très probablement, vous avez déjà fait de la gestion de versions. En effet, il suffit d'avoir créé une fois une copie d'un fichier dans l'optique de pouvoir le récupérer dans un deuxième moment, par exemple parce que vous allez essayer quelque chose de nouveau sur le fichier original. Cette pratique peut se répéter plusieurs fois et a souvent comme résultat une arborescence de fichiers du style :

mon_document.docx
mon_document2.docx
mon_document_revue.docx
mon_document_revue2.docx
mon_document_final.docx

Fondamentalement, la gestion de versions est une optimisation de cette démarche. Elle permet de mieux structurer le traçage des changements afin qu'on puisse se déplacer entre une version et l'autre. Idéalement, en effet, tous les changements concernent le fichier d'origine mon_document.docx. Les autres fichiers sont des spin-off créés pour différentes raisons, mais ils partagent avec le document d'origine la même finalité sémantique. La gestion de versions consiste donc à incorporer plusieurs versions du même fichier dans une seule référence. Nous verrons dans les exemples plus bas que ce mécanisme peut se faire de deux manières principales :

  • À travers le logiciel utilisé pour manipuler les fichiers spécifiques
    L'historique des versions est inclut dans le fichier lui-même et géré normalement par le même logiciel qui est utilisé pour manipuler le contenu du fichier (e.g. logiciel de traitement de texte, d'édition d'image, ...).
  • À travers un logiciel de gestion de versions
    L'historique des versions est géré par un outil externe qui permet de tracer plusieurs fichiers - et plusieurs types de fichiers différents - en même temps.

Dans les deux cas, les changements sont stockés dans un dépôt - en anglais on utilise souvent le terme repository - qui peut :

  • être visible de manière explicite ou à travers des manipulations plus avancées ;
  • être accessible d'une seule manière ou plusieurs ;
  • fournir de fonctionnalités pour agir sur les versions de manière plus ou moins sophistiquée ;
  • fournir des informations contextuelles aux changements sous forme de métadonnées plus ou moins détaillées ;
  • se trouver dans différents endroits, par exemple sur le même dispositif de l'utilisateur, dans un serveur distant, dans une application web, etc.

Sur le plan conceptuel, il peut être utile de définir la gestion de versions à travers les différences avec deux autres systèmes de gestion de fichiers : le backup et la synchronisation.

Différences avec le backup

La gestion de versions créé une forme implicite de backup, mais il s'agit plutôt d'un effet secondaire dû au traçage de l'évolution des fichiers. Le backup traditionnel présuppose de créer des copies des fichiers, généralement dans un autre dispositif, afin de pouvoir les récupérer en cas de problèmes techniques ou perte accidentelle. Par conséquent, backup et gestion de versions différent au moins sur les dimensions suivantes :

  • Conceptuelle
    Les fichiers de backup ne sont pas censés être utilisés dans le processus de travail ordinaire, ils interviennent en cas de situation extraordinaire. Au contraire, dans la gestion de versions, les différentes versions des fichiers peuvent être exploitées activement dans le processus de travail, par exemple pour créer des versions alternatives ou pour revenir à une version précédente.
  • Temporelle
    Les fichiers de backup partagent tous la même dimension temporelle qui corresponde à la dernière version des fichiers au moment où la sauvegarde de backup est effectuée. Dans la gestion de versions, au contraire, les fichiers disposent d'une double ligne temporelle, individuelle et de groupe, qui peuvent être parcourues séparément. Cet aspect confère beaucoup plus de flexibilité dans la gestion de versions.

Différences avec la synchronisation des fichiers

Lorsqu'elle est utilisée dans un contexte collaborative ou mise en place sur différents dispositifs avec un dépôt centralisé, la gestion de versions crée une forme implicite de synchronisation de fichiers, comme c'est le cas dans de gestionnaire des fichiers de type cloud comme Switchdrive, Google drive, OneDrive, Dropbox, etc. Comme pour le backup, cependant, il s'agit encore une fois d'un effet secondaire du traçage des changements. Gestion de versions et synchronisation des fichiers diffèrent au moins sur les dimensions suivantes :

  • Discrimination entre sauvegarde et version
    Dans la synchronisation des fichiers, toute sauvegarde est considérée de manière équivalente, car le moindre détail modifié est automatiquement propagé dans la synchronisation. Dans la gestion de versions, au contraire, l'utilisateur peut donner une connotation plus marquée au traçage d'un changement, par exemple en attendant plusieurs changements avant de soumettre une nouvelle version du fichier (ce qui n'empêche pas entre temps de sauvegarder le fichier) ou en qualifiant le changement à travers des métadonnées qui accompagnent la nouvelle version (e.g. une description de ce qui a été fait).
  • Direction des changements
    Dans la synchronisation des fichiers, la mise à jour est faite automatiquement de manière bi-directionnelle, c'est-à-dire que la version la plus récente du fichier est propagée et, par conséquent, remplace les versions précédentes dans tous les dispositifs connectées à la synchronisation. Dans la gestion de versions, au contraire, l'utilisateur peut généralement choisir dans quel direction propager les changements : (1) unidirectionnelle de ces fichiers au dépôt, (2) unidirectionnelle du dépôt à ces propres fichiers, ou (3) bi-directionnelle comme dans le cas de la synchronisation. Encore une fois, ce mécanisme confère à la gestion de versions plus de flexibilité.

Principes techniques de la gestion de versions

La gestion de versions peut sembler varier beaucoup en fonction du type de fichier et du logiciel qui est utilisé pour la mettre en oeuvre, mais en réalité le processus sous-jacent est basé sur le même principe fondamental : un fichier est une référence à de l'information qui est physiquement stockée dans la mémoire d'un dispositif individuel ou d'un serveur collectif. Lorsque cette information change, le fichier est modifié : la référence pointe maintenant à de l'information qui, physiquement, est stockée de manière différente par rapport à la version précédente.

Par exemple, si vous ajoutez des lignes à un fichier de texte, l'information associée au nom de votre fichier augmente, c'est-à-dire qu'elle occupe une partie plus étendue de la mémoire. Au contraire, si vous effacez des lignes, votre nom de fichier pointe vers une portion plus réduite de l'information. Même dans le cas où vous gardez la même longueur des lignes, mais vous changez quelques lettres, la manière dont votre information est encodée dans la mémoire se modifie, et votre nom de fichier pointe donc à de l'information qui est physiquement différente de la version précédente.

Par conséquent, un système de gestion de versions a comme objectif de pouvoir retracer des modifications physiques dans la mémoire et associer ces changements au même fichier ou ensemble de fichiers, sans avoir à créer des nouvelles références (i.e. des fichiers avec des noms différents) à chaque passage.

Fonctions principales de la gestion de versions

La gestion de versions peut varier en complexité et en fonctionnalités, mais en général on retrouve des fonctions qui sont plus ou moins communes aux différents systèmes. Les noms attribués aux fonctionnalités peuvent également changer en fonction du système spécifique utilisé, mais il est possible d'illustrer quelques fonctions principales à travers des descriptions des finalités. Dans cette section nous aborderons les suivantes :

  • Figer un fichier ou un ensemble de fichiers à un certain stade d'avancement
  • Revenir à une version précédente d'un fichier ou d'un ensemble de fichiers
  • Voir les différences entre une version et l'autre
  • Poursuivre des versions alternatives à travers des bifurcations
  • Intégrer des changements effectués par plusieurs personnes
  • Gérer des conflits d'intégration entre versions

Figer un stade d'avancement spécifique

Exemple de versionnage sémantique de Mediawiki, l'application web qui fait marcher ce wiki et également Wikipedia.

La gestion de versions permet de figer le stade d'avancement dans un fichier ou dans un ensemble de fichiers qui composent un projet. Conceptuellement, c'est l'équivalent de prendre une photo à un instant précis d'un phénomène dynamique qui est destiné à se modifier dans le temps : la photo est une représentation statique d'un moment précis, généralement avec une importance particulière. De la même manière, la gestion de versions permet de créer des ancrages dans l'évolution d'un projet qui ont une importance particulière.

Par exemple, dans le milieu du développement, on utilise souvent la gestion de versions en combinaison avec le versionnage sémantique : une pratique qui consiste à nommer les versions d'un logiciel ou d'une application avec 3 chiffres séparés par un point, comme par exemple 7.21.345. Le premier chiffre correspond à un changement majeur dans le logiciel, le deuxième à un changement mineur, et le troisième à un correctif ou patch. À travers la gestion de versions, il est possible de faire évoluer le projet selon ces axes sans avoir plusieurs copies du projet.

Revenir à une version précédente

Plusieurs logiciels et applications implémentent aujourd'hui la possibilité de revenir en arrière pour défaire une ou plusieurs opérations, notamment avec la combinaison des touches du clavier Ctrl + Z. La gestion de versions est une évolution à large échelle de ce mécanisme de base, car en utilisant des ancrages spécifiques (voir point précédent), il est toujours possible de revenir à une version des fichiers précédente.

Ce mécanisme peut être très utile par exemple dans le cas suivants :

  • Retracer quelle version du fichier a introduit un bug ou a ruiné le contenu du fichier ;
  • Maintenir une version fiable du fichier qui peut-être partagée pendant qu'on travaille à une version successive
  • Dans les environnements partagés et assez ouverts, comme par exemple ce wiki, Wikipedia, ou un document de texte partagé sur le web à travers un lien public, ce mécanisme permet de défaire des changements non pertinents (e.g. spam, hack, ...) apportés par des personnes ou des systèmes automatiques

Voir les différences entre une version et l'autre

Différences entre deux versions du contenu de cet article.

Une autre fonction principale de la gestion de versions consiste dans la possibilité de comparer les changements entre deux versions, afin de mettre en évidence ce qui a été modifié. Ce mécanisme est particulièrement utile pour les aspects suivants :

  • Il permet de focaliser l'attention sur les parties du fichier qui ont été modifiées, par exemple par d'autres personnes, au lieu d'avoir à réanalyser l'ensemble du contenu ;
  • Il peut être combiné avec le retour à une version précédente pour identifier précisément à quel moment et à quel endroit s'est manifesté un problème ;

En revanche, la lecture des différences peut nécessiter d'une certaine pratique car il peut y avoir souvent des caractères et des conventions graphiques à apprendre avant de pouvoir comprendre véritablement l'évolution des différences. Mais il existe également des systèmes où ces différences sont assez évidente, comme par exemple dans la comparaison entre contenus de deux versions d'une page wiki (voir image sur la droite).

Poursuivre des alternatives

Une fonction plus avancée de la gestion de versions, qui n'est pas toujours disponible dans tous les systèmes, consiste dans la possibilité de créer des bifurcation des projets afin de poursuivre des alternatives en parallèle. Techniquement, on se réfère souvent à ce concept avec le terme de branche en suivant la métaphore des branches des arbres qui, depuis un tronc commun, partent dans différentes directions. La métaphore est pertinente jusqu'à un certain point, car l'un des avantages des branches dans la gestion de versions consiste dans le fait que, à un certain point, on peut rejoindre à nouveau la voie principale en ajoutant les changements qui ont été effectués dans la voie parallèle.

Imaginez par exemple un jeu à plusieurs niveaux. Les premiers 2 niveaux ont déjà été développé (le tronc commun). À ce moment, dans l'équipe il n'y a pas d'accord sur comment poursuivre le troisième niveaux : deux idées différentes sont suggérées. Le responsable du jeu ne veut pas décider avant de voir à quoi ressemblent les niveaux et donc décident de poursuivre le développement deux deux versions du niveau 3, en créant donc deux branches parallèles. Une fois les deux versions du niveaux 3 développées, le responsable pourra décider laquelle utiliser, en l'incorporant dans la voie principale. L'autre version représente à ce moment un dead end, c'est-à-dire une branche qui ne sera plus poursuite. Le processus est représenté dans l'image ci bas.

Poursuivre des alternatives à travers des bifurcations

Un autre avantage collatérale de la gestion de versions implique que le niveau non retenu va continuer à exister dans les versions précédentes. Il pourrait à ce moment être repris dans un deuxième temps et intégré par exemple en tant que niveau 4 ou 5.

Intégrer des changements d'autres personnes

Gérer des conflits d'intégration

Exemples de gestion de versions

Logiciels de traitement de texte

Wiki

Git

Conclusion

Ressources