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

De EduTech Wiki
Aller à la navigation Aller à la recherche
 
(39 versions intermédiaires par 3 utilisateurs non affichées)
Ligne 3 : Ligne 3 :
== Introduction ==
== Introduction ==


La gestion de versions dans le milieu numérique se réfère 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'appliquer au niveau individuel ou dans des groupes de travail. La gestion de versions est originairement utilisée surtout dans le milieu de la [[Introduction à la programmation|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 [[CFAO|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]].
La gestion de versions également appelé historique de versions ou contrôle de versions (Angl. ''version control system'' (VCS)) se réfère, dans le milieu numérique, au stockage de plusieurs versions de fichier(s) afin de pouvoir tracer l'évolution chronologique à travers les changements apportés d'une version à l'autre. Elle peut s'appliquer à un fichier individuel (exemple : un document texte) ou à plusieurs milliers de fichiers d'un projet; elle peut se faire au niveau individuel ou dans des groupes de travail.  
A l'origine, la gestion de versions utilisée surtout dans le milieu de la [[Introduction à la programmation|programmation et du développement informatique]], mais elle s'utilise désormais de plus en plus dans des contextes différents comme par exemple l'[[écriture collaborative]], le ''Data Science'', la recherche, la [[CFAO|conception et fabrication assistées par ordinateur]], ou encore les processus de conception itératifs comme l'approche centrée utilisateur. Souvent, la gestion de versions est aussi à 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.
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.
Ligne 11 : Ligne 12 :
L'article à deux objectifs principaux :
L'article à deux objectifs principaux :


# 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 ;
# Introduire le concept de gestion de versions et sensibiliser des personnes sans background informatique aux avantages d'adopter un mécanisme de ce type dans ses propres flux de travail ;
# Illustrer quelques exemples de gestion de versions et de logiciels qui peuvent être utilisés pour les implémenter.
# 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.
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 peuvent être utile 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 ===
=== Prérequis ===
Ligne 26 : Ligne 27 :
== Principes conceptuels de la gestion de versions ==
== 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 :
Vous avez déjà probablement fait de la gestion de versions. En effet, il suffit d'avoir créé une fois une copie d'un fichier existant dans l'optique de pouvoir le récupérer à un autre moment. Par exemple, si vous voulez essayer quelque chose de nouveau et que vous faites une copie du fichier original afin d'obtenir une 2e version pour réaliser une expérimentation. 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_document.docx
Ligne 62 : Ligne 63 :
=== Différences avec la synchronisation des fichiers ===
=== 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ée, 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 :
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'''
* '''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).
*: 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'''
* '''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é.
*: 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 quelle 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 ==
== Principes techniques de la gestion de versions ==
Ligne 75 : Ligne 76 :
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 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.  
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.
 
D'un point de vue technique, on peut diviser les systèmes de gestion de versions en trois catégories déterminées par le ''siège'' physique du traçage des changements, c'est-à-dire où se trouve le ''dépôt'' dans lequel sont stockées les informations qui permettent de retracer les différents changements :
 
* Gestion de versions locale
* Gestion de versions centralisée
* Gestion de versions distribuée
 
=== Gestion de versions locale ===
 
[[Fichier:Gestion de versions locale.png|300px|vignette|droite|Gestion de versions locale.]]
Dans un système de gestion de versions '''locale''', le ''dépôt'' avec les changements se trouve physiquement sur la même machine qui stocke les fichiers tracés, comme par exemple :
 
* À l'intérieur du fichier même, comme les logiciels de traitement de texte (Microsoft Word par exemple),
* Dans un dossier qui se trouve au même endroit des fichiers de travail ou dans un autre parcours, mais toujours sur la même machine
 
Ce type de gestion de versions présente l'avantage de garder le traçage des changements à ''proximité'' des fichiers de travail, sans qu'il soit nécessaire de synchroniser avec une autre machine (e.g. un serveur distant). Dans les cas les plus simples, comme le traçage des changements dans un logiciel de traitement de texte, ce mécanisme présente également l'avantage que la gestion de versions peut être partagée automatiquement à travers le fichier de travail.
 
En revanche, la gestion locale ''pure'' est plus limitée en ce qui concerne la possibilité de collaborer et intégrer les changements d'autres personnes.
 
=== Gestion de versions centralisée ===
 
[[Fichier:Gestion de versions centralisée.png|300px|vignette|droite|Gestion de versions centralisée]]
Dans la gestion de versions '''centralisée''', le ''dépôt'' qui contient les informations sur les changements se trouve sur une autre machine par rapport aux fichiers de travail. Le cas de figure le plus commun consiste à garder le ''dépôt'' des changements sur un serveur centralisé, tandis que les différents ordinateurs individuels des personnes qui participent au projet ne gardent que la dernière version des fichiers de travail.
 
Ce type d'organisation présente l'avantage de centraliser les changements à un seul endroit, ce qui permet de libérer de l'espace dans les ordinateurs de travail. Une fois que la personne connectée au ''dépôt'' centrale décide de ''figer'' un changement, elle transmet l'information au serveur central qui enregistre la nouvelle version. À ce moment, le changement peut être propagé aux autres machines connectées au même dépôt. Cependant, comme nous l'avons vu dans la section sur les principes conceptuels, ce changement ne se propage en général pas de manière automatique comme dans les systèmes de synchronisation de fichiers de type ''cloud''. Les autres personnes connectées au dépôt peuvent en général être avertis de la nouvelle version de manière plus ou moins explicite. Ils seront au courant des changements en tout cas lorsqu'ils essayeront de mettre à jour leur projet par rapport au dépôt central.
 
=== Gestion de versions distribuée ===
 
[[Fichier:Gestion de versions distribuée.png|300px|vignette|droite|Gestion de versions distribuée]]
La gestion de versions '''distribuée''' combine la gestion de version locale et centralisée en créant '''''deux''' dépôts'' des changements :
 
# Le premier se trouve sur la même machine des fichiers de travail
# Le deuxième se trouve dans une autre machine, souvent un serveur ou une plateforme ''cloud'' comme [[GitHub]] ou [[GitLab]], qui s'occupe de centraliser les changements
 
La communication/synchronisation des changements se fait donc en deux passages :
 
* Entre les fichiers de travail et le dépôt local
* Entre le dépôt local et le dépôt centralisé
 
Ce passage ultérieur permet une plus grande flexibilité et ouvre également des possibilités supplémentaires, surtout d'un point de vue collaboratif. Par exemple :
 
* La personne peut apporter plusieurs changements au dépôt local avant de les envoyer au dépôt centralisé. D'ailleurs, la personne peut également décider de synthétiser plusieurs changements dans un seul changement plus conséquent, et envoyer seulement ce changement plus conséquent au dépôt centralisé.
* La personne dispose de l'ensemble de l'historique des changements même si elle n'est pas connectée au dépôt central, ce qui lui permet de travailler avec les versions en autonomie même en absence d'une connexion directe au dépôt central.
* La personne peut décider de se débrancher du dépôt central et rendre le projet indépendant, tout en gardant l'historique jusqu'à ce point. Le projet peut à ce moment devenir un autre dépôt central et continuer de manière indépendante du dépôt central originaire.
 
La gestion distribuée est notamment l'un des éléments principaux des projets open source, comme il est représenté dans l'image ci-bas.
 
[[Fichier:Git et GitHub dans un projet open-source.png|800px|vignette|néant|Utilisation de la gestion de versions distribuée dans un projet open source.]]
 
Dans ce schéma qui utilise [[Git]] et [[GitHub]] comme exemple (mais le même principe peut-être appliqué à d'autres systèmes), le dépôt local se trouve dans un dossier <code>.git</code> sur l'ordinateur d'une personne. Ce dépôt local est partagé en open source à travers un dépôt central qui se trouve sur la plateforme ''cloud'' [[GitHub]]. Ce dépôt central peut être utilisé par plusieurs personnes pour :
 
* Contribuer au même projet, c'est-à-dire envoyer des changements qui sont ensuite incorporer dans le dépôt central et peuvent donc être ensuite propagés à tout dépôt local connecté
* Utiliser ce dépôt central comme base pour un autre projet, dans un mécanisme de ''spin-off'' qui hérite du dépôt original toute l'histoire des changements jusqu'à ce moment, mais qui prend ''sa propre route'' par la suite


== Fonctions principales de la gestion de versions ==
== 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 :
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 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
* ''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
* 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''
* Poursuivre des versions alternatives à travers des ''bifurcations''
* Intégrer des changements effectués par plusieurs personnes
* Intégrer des changements effectués par plusieurs personnes et gérer les conflits
* Gérer des conflits d'intégration entre versions
 
=== ''Figer'' un stade d'avancement spécifique ===
 
[[Fichier:Versionnage semantique exemple mediawiki.png|300px|vignette|droite|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.


=== Figer un stade d'avancement ===
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 <code>7.21.345</code>. 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 ===
=== 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 <code>Ctrl + Z</code>. 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 ===
[[Fichier:Détail des différences entre deux versions d'une page wiki.png|300px|vignette|droite|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 à 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 une certaine pratique car il peut y avoir des caractères et 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 ===
=== Poursuivre des alternatives ===


=== Intégrer des changements d'autres personnes ===
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  deux premiers 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 des 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 poursuivie. Le processus est représenté dans l'image ci-dessous.
 
[[Fichier:Gestion de versions poursuivre alternatives.png|600px|vignette|néant|Poursuivre des alternatives à travers des ''bifurcations'']]
 
Un autre avantage collatéral 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égration des changements et gestion de conflits ===
 
Surtout dans un contexte collaboratif, il est important de pouvoir assimiler les différents changements apportés par plusieurs personnes dans le même ''tronc commun''. Les systèmes de gestion de versions peuvent aider dans cette démarche qui peut s'avérer parfois compliqué, notamment lorsque des conflits entre versions se manifestent.
 
Un conflit entre versions surgit lorsque deux versions du même fichier ont apportés des modifications à du contenu déjà existant, mais de deux manières différentes. Selon le système de version utilisé, des mécanismes plus ou moins complexes peuvent se mettre en place pour détecter et signaler précisément à quel endroit le conflit est apparu et proposer des solutions pour le résoudre.


=== Gérer des conflits d'intégration ===
L'intégration des changements et la gestion de conflits est néanmoins une fonctionnalité plus avancée de la gestion de versions est il est difficile de la traiter de manière abstraite. Les personnes intéressées peuvent se référer directement à des systèmes de gestions qui prennent en charge ces fonctionnalités, comme par exemple [[Git]].


== Exemples de gestion de versions ==
== Exemples de gestion de versions ==
=== Logiciels de traitement de texte ===
Plusieurs logiciels de traitement de texte, surtout dans les versions en ligne et collaboratives, permettent de retracer l'historique des versions. Très souvent, les versions sont sauvegardées de manière automatique, sans que l'utilisateur doive expliciter la sauvegarde d'une version. Cette approche a l'avantage de gérer automatiquement la gestion des versions, mais le désavantage de ne pas permettre une hiérarchie des modifications.
La gestion de versions dans les logiciels de traitement de texte n'est parfois pas visible de manière explicite. Il faut souvent chercher dans la documentation en ligne ou explorer l'interface. Parfois, la gestion de versions se trouve en proximité des messages de sauvegarde.
=== Wiki ===
La gestion de versions, appelée dans ce contexte souvent '''historique des versions''', est l'une des fonctionnalités principales caractérisant tout système qui s'inspire du principe [[wiki]]. Des systèmes de ce type peuvent se trouver à plusieurs endroits, avec des fonctionnalités légèrement différentes, comme par exemple dans :
* [[Moodle]], une [[plateforme pédagogique]] très utilisée dans la formation et l'enseignement (voir par exemple [https://docs.moodle.org/3x/fr/Wiki la documentation officielle] de la version 3 de Moodle)
* Les dépôts [[GitHub]], dans lesquels le [[wiki]] est souvent utilisé comme documentation ou moyen d'organisation entre collaborateurs (voir par exemple [https://help.github.com/en/github/building-a-strong-community/about-wikis About wikis] dans la documentation officielle)
* Tous les sites qui sont basés sur un ''moteur'' wiki, comme par exemple [[Mediawiki|MediaWiki]], le logiciel open-source à la base de [[Wikipédia]] et également de EduTech Wiki
Dans cette section nous utiliserons précisément les fonctionnalités d'historique des versions mises à disposition à travers [[Mediawiki|MediaWiki]] et appliquées à des pages EduTech Wiki, en sachant que les mêmes principes s'appliquent, au moins conceptuellement, à d'autres environnements [[wiki]]. Nous aborderons les aspects suivants : (1) comment accéder et ''lire'' l'historique des versions ; (2) quelques manipulations possibles à travers l'historique des versions ; et (3) comment citer une page EduTech Wiki pour montrer que l'historique des versions n'a pas seulement un rôle technique, mais peut également servir de ''mémoire'' documentale.
=== Git ===


== Conclusion ==
== Conclusion ==

Dernière version du 1 mars 2021 à 15:42

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 (Angl. version control system (VCS)) se réfère, dans le milieu numérique, au stockage de plusieurs versions de fichier(s) afin de pouvoir tracer l'évolution chronologique à travers les changements apportés d'une version à l'autre. Elle peut s'appliquer à un fichier individuel (exemple : un document texte) ou à plusieurs milliers de fichiers d'un projet; elle peut se faire au niveau individuel ou dans des groupes de travail. A l'origine, la gestion de versions utilisée surtout dans le milieu de la programmation et du développement informatique, mais elle s'utilise désormais de plus en plus 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. Souvent, la gestion de versions est aussi à 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 background informatique aux avantages d'adopter un mécanisme de ce type dans ses propres flux 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 peuvent être utile 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

Vous avez déjà probablement fait de la gestion de versions. En effet, il suffit d'avoir créé une fois une copie d'un fichier existant dans l'optique de pouvoir le récupérer à un autre moment. Par exemple, si vous voulez essayer quelque chose de nouveau et que vous faites une copie du fichier original afin d'obtenir une 2e version pour réaliser une expérimentation. 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 quelle 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.

D'un point de vue technique, on peut diviser les systèmes de gestion de versions en trois catégories déterminées par le siège physique du traçage des changements, c'est-à-dire où se trouve le dépôt dans lequel sont stockées les informations qui permettent de retracer les différents changements :

  • Gestion de versions locale
  • Gestion de versions centralisée
  • Gestion de versions distribuée

Gestion de versions locale

Gestion de versions locale.

Dans un système de gestion de versions locale, le dépôt avec les changements se trouve physiquement sur la même machine qui stocke les fichiers tracés, comme par exemple :

  • À l'intérieur du fichier même, comme les logiciels de traitement de texte (Microsoft Word par exemple),
  • Dans un dossier qui se trouve au même endroit des fichiers de travail ou dans un autre parcours, mais toujours sur la même machine

Ce type de gestion de versions présente l'avantage de garder le traçage des changements à proximité des fichiers de travail, sans qu'il soit nécessaire de synchroniser avec une autre machine (e.g. un serveur distant). Dans les cas les plus simples, comme le traçage des changements dans un logiciel de traitement de texte, ce mécanisme présente également l'avantage que la gestion de versions peut être partagée automatiquement à travers le fichier de travail.

En revanche, la gestion locale pure est plus limitée en ce qui concerne la possibilité de collaborer et intégrer les changements d'autres personnes.

Gestion de versions centralisée

Gestion de versions centralisée

Dans la gestion de versions centralisée, le dépôt qui contient les informations sur les changements se trouve sur une autre machine par rapport aux fichiers de travail. Le cas de figure le plus commun consiste à garder le dépôt des changements sur un serveur centralisé, tandis que les différents ordinateurs individuels des personnes qui participent au projet ne gardent que la dernière version des fichiers de travail.

Ce type d'organisation présente l'avantage de centraliser les changements à un seul endroit, ce qui permet de libérer de l'espace dans les ordinateurs de travail. Une fois que la personne connectée au dépôt centrale décide de figer un changement, elle transmet l'information au serveur central qui enregistre la nouvelle version. À ce moment, le changement peut être propagé aux autres machines connectées au même dépôt. Cependant, comme nous l'avons vu dans la section sur les principes conceptuels, ce changement ne se propage en général pas de manière automatique comme dans les systèmes de synchronisation de fichiers de type cloud. Les autres personnes connectées au dépôt peuvent en général être avertis de la nouvelle version de manière plus ou moins explicite. Ils seront au courant des changements en tout cas lorsqu'ils essayeront de mettre à jour leur projet par rapport au dépôt central.

Gestion de versions distribuée

Gestion de versions distribuée

La gestion de versions distribuée combine la gestion de version locale et centralisée en créant deux dépôts des changements :

  1. Le premier se trouve sur la même machine des fichiers de travail
  2. Le deuxième se trouve dans une autre machine, souvent un serveur ou une plateforme cloud comme GitHub ou GitLab, qui s'occupe de centraliser les changements

La communication/synchronisation des changements se fait donc en deux passages :

  • Entre les fichiers de travail et le dépôt local
  • Entre le dépôt local et le dépôt centralisé

Ce passage ultérieur permet une plus grande flexibilité et ouvre également des possibilités supplémentaires, surtout d'un point de vue collaboratif. Par exemple :

  • La personne peut apporter plusieurs changements au dépôt local avant de les envoyer au dépôt centralisé. D'ailleurs, la personne peut également décider de synthétiser plusieurs changements dans un seul changement plus conséquent, et envoyer seulement ce changement plus conséquent au dépôt centralisé.
  • La personne dispose de l'ensemble de l'historique des changements même si elle n'est pas connectée au dépôt central, ce qui lui permet de travailler avec les versions en autonomie même en absence d'une connexion directe au dépôt central.
  • La personne peut décider de se débrancher du dépôt central et rendre le projet indépendant, tout en gardant l'historique jusqu'à ce point. Le projet peut à ce moment devenir un autre dépôt central et continuer de manière indépendante du dépôt central originaire.

La gestion distribuée est notamment l'un des éléments principaux des projets open source, comme il est représenté dans l'image ci-bas.

Utilisation de la gestion de versions distribuée dans un projet open source.

Dans ce schéma qui utilise Git et GitHub comme exemple (mais le même principe peut-être appliqué à d'autres systèmes), le dépôt local se trouve dans un dossier .git sur l'ordinateur d'une personne. Ce dépôt local est partagé en open source à travers un dépôt central qui se trouve sur la plateforme cloud GitHub. Ce dépôt central peut être utilisé par plusieurs personnes pour :

  • Contribuer au même projet, c'est-à-dire envoyer des changements qui sont ensuite incorporer dans le dépôt central et peuvent donc être ensuite propagés à tout dépôt local connecté
  • Utiliser ce dépôt central comme base pour un autre projet, dans un mécanisme de spin-off qui hérite du dépôt original toute l'histoire des changements jusqu'à ce moment, mais qui prend sa propre route par la suite

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 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 et gérer les conflits

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 à 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 une certaine pratique car il peut y avoir des caractères et 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 deux premiers 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 des 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 poursuivie. Le processus est représenté dans l'image ci-dessous.

Poursuivre des alternatives à travers des bifurcations

Un autre avantage collatéral 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égration des changements et gestion de conflits

Surtout dans un contexte collaboratif, il est important de pouvoir assimiler les différents changements apportés par plusieurs personnes dans le même tronc commun. Les systèmes de gestion de versions peuvent aider dans cette démarche qui peut s'avérer parfois compliqué, notamment lorsque des conflits entre versions se manifestent.

Un conflit entre versions surgit lorsque deux versions du même fichier ont apportés des modifications à du contenu déjà existant, mais de deux manières différentes. Selon le système de version utilisé, des mécanismes plus ou moins complexes peuvent se mettre en place pour détecter et signaler précisément à quel endroit le conflit est apparu et proposer des solutions pour le résoudre.

L'intégration des changements et la gestion de conflits est néanmoins une fonctionnalité plus avancée de la gestion de versions est il est difficile de la traiter de manière abstraite. Les personnes intéressées peuvent se référer directement à des systèmes de gestions qui prennent en charge ces fonctionnalités, comme par exemple Git.

Exemples de gestion de versions

Logiciels de traitement de texte

Plusieurs logiciels de traitement de texte, surtout dans les versions en ligne et collaboratives, permettent de retracer l'historique des versions. Très souvent, les versions sont sauvegardées de manière automatique, sans que l'utilisateur doive expliciter la sauvegarde d'une version. Cette approche a l'avantage de gérer automatiquement la gestion des versions, mais le désavantage de ne pas permettre une hiérarchie des modifications.

La gestion de versions dans les logiciels de traitement de texte n'est parfois pas visible de manière explicite. Il faut souvent chercher dans la documentation en ligne ou explorer l'interface. Parfois, la gestion de versions se trouve en proximité des messages de sauvegarde.

Wiki

La gestion de versions, appelée dans ce contexte souvent historique des versions, est l'une des fonctionnalités principales caractérisant tout système qui s'inspire du principe wiki. Des systèmes de ce type peuvent se trouver à plusieurs endroits, avec des fonctionnalités légèrement différentes, comme par exemple dans :

  • Moodle, une plateforme pédagogique très utilisée dans la formation et l'enseignement (voir par exemple la documentation officielle de la version 3 de Moodle)
  • Les dépôts GitHub, dans lesquels le wiki est souvent utilisé comme documentation ou moyen d'organisation entre collaborateurs (voir par exemple About wikis dans la documentation officielle)
  • Tous les sites qui sont basés sur un moteur wiki, comme par exemple MediaWiki, le logiciel open-source à la base de Wikipédia et également de EduTech Wiki

Dans cette section nous utiliserons précisément les fonctionnalités d'historique des versions mises à disposition à travers MediaWiki et appliquées à des pages EduTech Wiki, en sachant que les mêmes principes s'appliquent, au moins conceptuellement, à d'autres environnements wiki. Nous aborderons les aspects suivants : (1) comment accéder et lire l'historique des versions ; (2) quelques manipulations possibles à travers l'historique des versions ; et (3) comment citer une page EduTech Wiki pour montrer que l'historique des versions n'a pas seulement un rôle technique, mais peut également servir de mémoire documentale.

Git

Conclusion

Ressources