La gestion de versions (en anglais version control ou revision control) est une activité qui consiste à maintenir l'ensemble des versions ou révisions d'un logiciel ou autre document. Essentiellement utilisée dans le domaine de la création de logiciels, elle est surtout concernée par le code source ; mais elle peut être utilisée pour tout type de document informatique.
Cette activité étant fastidieuse et relativement complexe, un appui logiciel est presque indispensable. À cet effet, il existe différents logiciels de gestion de versions qui, bien qu'ayant des concepts essentiels communs, apportent chacun son propre vocabulaire et ses propres usages. À titre d'exemple, on trouve un mécanisme de gestion de versions dans Wikipédia : pour chaque article, l'historique est disponible en cliquant sur le lien Afficher l'historique.
Les logiciels évoluant, chaque étape d'avancement est appelée version. Les différentes versions sont nécessairement liées à travers des modifications.
Une modification peut correspondre à des ajouts, modifications, suppressions ou une combinaison des trois sur une version donnée. Schématiquement, on passera de la version N à la version N + 1 en appliquant une modification M. Un logiciel de gestion de versions nous aidera alors à soustraire la modification M de la version N + 1 pour retrouver la version N.
Les concepteurs du logiciel de gestion de versions RCS ont choisi de parler de « révisions » (revisions) afin de ne pas confondre la version du logiciel avec les « révisions » de ses fichiers sources.
Pour des raisons pratiques, on associe généralement un « numéro » à une version (voir Version d'un logiciel).
Avant toute modification, le développeur effectue une copie locale des fichiers qu'il souhaite modifier, voire de tous les fichiers du logiciel. Selon les systèmes de gestion de version, il disposera des droits d'écriture sur tous les fichiers ou seulement sur les fichiers qui lui auront été assigné par le chef de projet, il pourra poser ou non des verrous que d'autres utilisateurs pourront ou non contourner, etc.
Le développeur modifie ce qu'il doit modifier et effectue ses premiers tests localement, indépendamment de toutes les modifications qui pourraient advenir dans les dépôts du fait du travail simultané d'autres développeurs.
Lorsque le développeur veut livrer son travail, que celui-ci soit totalement terminé ou non, il doit soumettre ses modifications afin qu'elles soient retranscrites dans le dépôt. C'est là que peuvent apparaître des conflits entre ce que le développeur souhaite soumettre et les modifications effectuées entre temps par d'autres personnes.
Une modification constitue donc l'évolution entre deux versions. On peut donc aussi bien parler de la différence entre deux versions que de modifications ayant amené à une nouvelle version.
On utilise généralement la gestion de versions à un ensemble de fichiers qui constitue un projet. De ce fait, il est courant de parler de modifications pour un seul fichier et d'ensemble de modifications (change set) lorsqu'il s'agit du projet (et donc de plusieurs fichiers). En effet, les deux n'évoluent pas au même rythme.
Pour illustrer, prenons l'exemple d'un logiciel nommé « Toto ». Il est constitué des fichiers A, B et C. À la version 1.0 de « Toto » correspondent les versions 1.0 de chacun des fichiers. Admettons que l'ajout d'une fonctionnalité à « Toto » impose la modification de A et de C. Présentons la situation à l'aide d'un tableau
versions de « Toto » | versions de A | versions de B | versions de C |
---|---|---|---|
1.0 | 1.0 | 1.0 | 1.0 |
1.1 | 1.1 | 1.1 |
Du point de vue du projet, les modifications apportées à A et à C font partie du même ensemble.