introduction
Je propose de discuter de l'objectif et des différentes manières d'organiser les systèmes de contrôle de version.
Systèmes de contrôle de version
Un système de contrôle de version est avant tout un outil, et un outil est conçu pour résoudre une certaine classe de problèmes. Ainsi, un système de contrôle de version est un système qui enregistre les modifications apportées
à un fichier ou à un ensemble de fichiers au fil du temps et vous permet de revenir ultérieurement à une version spécifique. Nous voulons gérer de manière flexible un certain ensemble de fichiers, revenir à certaines versions si nécessaire. Vous pouvez annuler certaines modifications du fichier, annuler sa suppression, voir qui a changé quelque chose. En règle générale, les systèmes de contrôle de version sont utilisés pour stocker le code source, mais ce n'est pas obligatoire. Ils peuvent être utilisés pour stocker tout type de fichier.
Comment stocker différentes versions de fichiers? Les gens ne sont pas venus tout de suite à un outil tel que les systèmes de contrôle de version, et ils sont eux-mêmes très différents. Le problème proposé peut être résolu en utilisant de bons vieux systèmes de contrôle de version copier-coller, locaux, centralisés ou distribués.
Copier coller
Une méthode bien connue, appliquée à ce problème, peut ressembler à ceci: nous nommerons les fichiers par le motif filename_ {version}, éventuellement avec l'ajout de l'heure de création ou de modification.
Cette méthode est très simple, mais elle est sujette à diverses erreurs: vous pouvez accidentellement changer le mauvais fichier, vous pouvez copier à partir du mauvais répertoire (après tout, c'est ainsi que les fichiers sont transférés dans ce modèle).
Système de contrôle de version local
L'étape suivante du développement des systèmes de contrôle de version a été la création de systèmes de contrôle de version locaux. Il s'agissait d'une simple base de données qui enregistre toutes les modifications apportées aux fichiers.
Un exemple de tels systèmes est le système de contrôle de version RCS, qui a été développé en 1985 (le dernier correctif a été écrit en 2015) et stocke les modifications dans les fichiers (correctifs) tout en maintenant le contrôle de version. Un ensemble de ces modifications vous permet de restaurer n'importe quel état du fichier. RCS est livré avec Linux.
Le système de contrôle de version local fait un bon travail pour résoudre le problème, mais son problème est la propriété principale - la localité. Il n'est pas du tout destiné à un usage collectif.
Système de contrôle de version centralisé
Le système de contrôle de version centralisé est conçu pour résoudre le problème de base du système de contrôle de version local.
Pour organiser un tel système de contrôle de version, un seul serveur est utilisé qui contient toutes les versions de fichiers. Les clients accédant à ce serveur proviennent de ce référentiel centralisé. L'utilisation de systèmes de contrôle de version centralisés est la norme depuis de nombreuses années. Ceux-ci incluent CVS, Subversion, Perforce.
Ces systèmes sont faciles à gérer grâce à un seul serveur. Mais en même temps, la présence d'un serveur centralisé conduit à l'émergence d'un point de défaillance unique sous la forme de ce serveur lui-même. Si ce serveur est désactivé, les développeurs ne pourront pas télécharger de fichiers. Le pire des scénarios est la destruction physique du serveur (ou le crash du disque dur), qui conduit à la perte de la base de code.
Malgré le fait que la mode pour SVN soit passée, il y a parfois un cours inverse - la transition de Git à SVN. Le fait est que SVN permet une extraction sélective, ce qui implique de télécharger uniquement certains fichiers à partir du serveur. Cette approche gagne en popularité lors de l'utilisation de monorépôts, ce qui peut être discuté plus tard.
Système de contrôle de version distribué
Les systèmes de contrôle de version distribués sont utilisés pour éliminer un point de défaillance unique. Ils impliquent que le client téléchargera le référentiel entier pour lui-même au lieu de télécharger des fichiers spécifiques d'intérêt pour le client. Si une copie du référentiel meurt, cela n'entraînera pas la perte de la base de code, car elle peut être restaurée à partir de l'ordinateur de n'importe quel développeur. Chaque copie est une sauvegarde complète des données.
Toutes les copies sont égales et peuvent être synchronisées les unes avec les autres. Cette approche est très similaire à (et est en fait) la réplication maître-maître.
Ce type de système de contrôle de version comprend Mercurial, Bazaar, Darcs et Git. Le dernier système de contrôle de version sera discuté plus en détail ci-dessous.
Histoire de Git
En 2005, la société de contrôle de version BitKeeper a rompu ses liens avec la communauté du noyau Linux. La communauté a alors décidé de développer son propre système de contrôle de version. Les principales valeurs du nouveau système sont: décentralisation complète, rapidité, architecture simple, bon support pour le développement non linéaire.
Conclusion
Nous avons examiné les manières d'organiser les systèmes de contrôle de version, discuté des options pour résoudre les tâches assignées à ces systèmes, parlé des avantages et des inconvénients de chacun d'eux, pris connaissance de l'histoire du système de contrôle de version Git.