Ashok est un développeur iOS et un professionnel de l’ingénierie. Il a obtenu une maîtrise en applications informatiques avec un accent sur la programmation.
Qu’est-ce que le contrôle de version ?
Le contrôle de version, également connu sous le nom de contrôle de source, est la pratique consistant à suivre et à gérer les modifications apportées au code logiciel. Les systèmes de contrôle de version sont des outils logiciels qui aident les équipes logicielles à gérer les modifications apportées au code source au fil du temps. Il permet à l’équipe de développement de contribuer et de gérer différentes versions et étapes de produits logiciels sans avoir à conserver plusieurs fichiers ou dossiers. Cela rend également le développement au sein d’une équipe plus gérable et moins pénible.
Objectif du contrôle de version
- Plusieurs personnes peuvent travailler simultanément sur un même projet. Chacun travaille et édite sa propre copie des fichiers et c’est à lui de décider s’il souhaite partager les modifications qu’il a apportées avec le reste de l’équipe.
- Permet à une personne d’utiliser plusieurs ordinateurs pour travailler sur un projet.
- Il intègre le travail effectué simultanément par différents membres de l’équipe.
- Le contrôle de version permet d’accéder aux versions historiques d’un projet. Il s’agit d’une assurance contre les pannes informatiques ou la perte de données. Si une erreur est commise, nous pouvons facilement revenir à une version précédente. Il est également possible d’annuler des modifications spécifiques sans perdre le travail effectué entre-temps.
- Il est facile de savoir quand, pourquoi et par qui une partie d’un fichier a été modifiée.
Avantages du système de contrôle de version
- Gestion et protection du code source.
- Complétez l’historique des modifications à long terme de chaque fichier. Il conserve tous les changements apportés par de nombreuses personnes au fil des ans.
- Améliore la vitesse de développement du projet en offrant une collaboration efficace.
- Comparaison des versions antérieures du code
- Tire parti de la productivité, accélère la livraison des produits et les compétences des employés grâce à une meilleure communication et assistance,
- Réduisez les possibilités d’erreurs et de conflits pendant le développement du projet grâce à la traçabilité de chaque petit changement.
- Les membres de l’équipe ou les contributeurs du projet peuvent contribuer de n’importe où, indépendamment des différents emplacements géographiques, via VCS.
- Pour chaque contributeur différent au projet, une copie de travail différente est conservée et non fusionnée avec le fichier principal à moins que la copie de travail ne soit validée.
- Aide à la récupération en cas de catastrophe ou de situation contingente.
- Informe sur qui, quoi, quand et pourquoi les modifications ont été apportées.
Il existe deux types de systèmes de contrôle de version : centralisé et distribué.
1. Systèmes de contrôle de version centralisés
Dans un système de contrôle de version centralisé (CVCS), un serveur agit comme le référentiel principal qui stocke chaque version de code. Les systèmes de contrôle de version centralisés sont basés sur l’idée qu’il existe une seule copie « centrale » de votre projet quelque part (probablement sur un serveur), et qu’un membre de l’équipe « validera » ses modifications sur cette copie centrale. En utilisant le contrôle de source centralisé, chaque utilisateur s’engage directement dans la branche principale, donc ce type de contrôle de version fonctionne souvent bien pour les petites équipes, car les membres de l’équipe ont la possibilité de communiquer rapidement afin que deux développeurs ne veuillent pas travailler sur le même morceau de code simultanément.
Les systèmes de contrôle de source centralisés, tels que CVS, Perforce et SVN, obligent les utilisateurs à extraire la dernière version du serveur pour télécharger une copie locale sur leur machine. Les contributeurs poussent ensuite les commits vers le serveur et résolvent tout conflit de fusion sur le référentiel principal.
Avantages
- Fonctionne bien avec les fichiers binaires
- Offre une visibilité complète
- Accorder le contrôle du niveau d’accès au niveau du répertoire
- Relativement facile à mettre en place
- Fournit de la transparence
- Plus de contrôle sur les utilisateurs et leurs accès.
Désavantages
- Si le serveur principal tombe en panne, les développeurs ne peuvent pas enregistrer les modifications versionnées.
- Il n’est pas disponible localement, ce qui signifie que nous devons nous connecter au réseau pour effectuer des opérations.
- Les commits à distance sont lents. Pour chaque commande, CVCS connecte le serveur central ce qui impacte la vitesse de fonctionnement.
- Pendant les opérations, si le serveur central tombe en panne, il y a de fortes chances de perdre les données.
2. Systèmes de contrôle de version distribués
Dans le contrôle de version distribué, la plupart du mécanisme ou du modèle s’applique de la même manière que centralisé. La seule différence majeure ici est qu’au lieu d’un référentiel unique, qui est le serveur, chaque développeur ou client a son propre serveur et ils auront une copie de l’intégralité de l’historique ou de la version du code et de toutes ses branches sur leur serveur local. ou machine. Cela signifie que chacun dispose d’une copie de travail du référentiel qui garde une trace de ses modifications et des différentes versions réalisées par lui ou par ses collègues.
Git et Mercurial sont les systèmes distribués les plus utilisés en génie logiciel.
Avantages
- Sauf pour pousser et tirer le code, l’utilisateur peut travailler hors ligne dans DVCS, grâce à cela, l’historique complet est toujours disponible.
- DVCS est plus rapide que CVCS car vous n’avez pas besoin de communiquer avec le serveur distant pour chaque commande.
- Fusionner et ramifier les changements dans DVCS est très facile.
- Pas besoin d’accéder à un serveur distant donc les performances de DVCS sont meilleures.
- Si le serveur principal tombe en panne ou tombe en panne dans DVCS, vous pouvez toujours obtenir la sauvegarde ou l’historique complet du code à partir de votre référentiel ou serveur local où la révision complète du code est déjà enregistrée.
- En raison des commits locaux, l’historique complet est toujours disponible.
- Capacité à pousser vos changements en continu
- Bon pour les projets avec des développeurs offshore
Désavantages
- Travailler avec beaucoup de fichiers binaires nécessite une énorme quantité d’espace, et les développeurs ne peuvent pas faire de diffs.
- Les projets avec une longue histoire, c’est-à-dire un grand nombre d’ensembles de modifications peuvent prendre beaucoup de temps et occuper plus d’espace disque.
- Il n’est pas toujours évident de savoir qui a effectué le changement le plus récent
- Le verrouillage de fichiers ne permet pas à différents développeurs de travailler simultanément sur le même morceau de code. Cela permet d’éviter les conflits de fusion mais ralentit le développement.
- DVCS vous permet de cloner le référentiel – cela pourrait signifier un problème de sécurité
- La gestion des fichiers non fusionnables est contraire au concept DVCS
DVCS contre CVCS
- DVCS se concentre sur le partage des modifications ; chaque changement a un guid ou un identifiant unique.
- Chaque développeur dispose d’une copie locale du référentiel de code source, en plus du référentiel de code source central.
- Les systèmes distribués n’ont pas de structure forcée. Vous pouvez créer des emplacements « administrés de manière centralisée » ou garder tout le monde comme pairs.
- DVCS permet de travailler hors ligne. Hormis les actions push et pull, tout se fait localement.
- CVCS se concentre sur la synchronisation, le suivi et la sauvegarde des fichiers.
- CVCS fonctionne sur la base d’une relation client-serveur, avec le référentiel source situé sur un seul serveur, offrant un accès aux développeurs du monde entier.
- L’enregistrement/le téléchargement et l’application d’une modification sont des étapes distinctes dans un système centralisé, elles se déroulent ensemble.
- CVCS s’appuie sur la connectivité Internet pour accéder au serveur.
Termes clés populaires
Dépôt: Il peut être décrit comme le cœur de tout système de contrôle de version. C’est l’endroit central défini où tous les développeurs ou programmeurs travaillent et stockent leur code. Outre le stockage des fichiers, les référentiels conservent également l’historique. Dans les systèmes de contrôle de version, les référentiels sont accessibles via un réseau qui agit comme un serveur et un outil de contrôle de version en tant que client. Lors de l’établissement de connexions réussies, les clients stockent ou récupèrent leurs modifications.
Tronc: Un tronc peut être défini comme un répertoire où tout le développement a lieu. Toutes les caisses sont engagées par les développeurs.
Mots clés: Les balises aident à créer des instantanés du projet. L’opération de création de balises permet de conserver des noms descriptifs et mémorisables à une version spécifique dans le référentiel.
Branches: Les branches du référentiel sont comme les branches de l’arborescence. L’opération de création de branches sert à créer une autre ligne de développement. Il s’avère bénéfique lorsque votre processus de développement bifurque dans deux directions.
Copie de travail : C’est l’instantané du référentiel sur lequel le développeur travaille activement. Chaque développeur a sa propre copie de travail. Les modifications apportées à la copie de travail sont fusionnées dans le référentiel principal. Une copie de travail peut être considérée comme un lieu de travail privé où les développeurs entretiennent leur travail de manière systématique et isolé du reste des développeurs.
Valider les modifications : La validation du code est le processus de stockage des modifications d’une copie de travail sur le serveur central. Une fois la validation réussie, les modifications sont mises à la disposition de tous les membres de l’équipe. D’autres développeurs peuvent extraire ces modifications qui mettront à jour la copie de travail. La validation est une opération atomique, ce qui signifie qu’elle est réussie ou annulée. Les développeurs ne peuvent jamais voir un commit à moitié terminé.
Révision: Un brouillon numéroté de mises à jour spécifiques à des fichiers individuels. Chaque fois que vous modifiez un fichier et que vous le remettez dans le référentiel, le numéro de révision du fichier augmente.
Version: Le système de numérotation est utilisé pour identifier ensembles de fichiers qui sont étiquetés et nommés à un certain moment.
Conflit: Lorsque deux développeurs apportent des modifications à leurs copies de travail du même fichier et les valident dans le référentiel, leur travail peut entrer en conflit. Lorsque cela se produit, CVS détecte le conflit et demande à quelqu’un de le résoudre avant de valider ses modifications.
Fusion : Combinaison de plusieurs modifications apportées à différentes copies de travail des mêmes fichiers dans le référentiel source. La fusion est une stratégie de gestion des conflits en permettant à plusieurs développeurs de travailler en même temps (sans verrous sur les fichiers), puis en incorporant leur travail dans une version combinée. La fusion fonctionne bien lorsque deux ensembles de modifications sont apportées à différentes lignes dans des fichiers et peuvent être facilement combinées. Lorsque des modifications sont apportées à un fichier sur la ou les mêmes lignes, des conflits se produisent, nécessitant que quelqu’un modifie le fichier manuellement avant que les modifications puissent être validées avec succès dans le référentiel source.
Résoudre : Les conflits au sein d’un fichier créé par deux développeurs tentant de valider des modifications conflictuelles doivent être résolus en modifiant manuellement le fichier. Quelqu’un doit parcourir le fichier ligne par ligne pour accepter un ensemble de modifications et supprimer l’autre ensemble. Les fichiers avec des conflits ne peuvent pas être correctement validés dans le référentiel source tant qu’ils ne sont pas résolus.
Cet article est exact et fidèle au meilleur de la connaissance de l’auteur. Le contenu est uniquement à des fins d’information ou de divertissement et ne remplace pas un conseil personnel ou un conseil professionnel en matière commerciale, financière, juridique ou technique.
