Contrôle de version

Un article de Wikipédia, l'encyclopédie libre
Aller à la navigation Aller à la recherche

En génie logiciel , le contrôle de version (également appelé contrôle de révision , contrôle de source ou gestion de code source ) est une classe de systèmes chargés de gérer les modifications apportées aux programmes informatiques , aux documents, aux grands sites Web ou à d'autres collections d'informations. Le contrôle de version est un composant de la gestion de la configuration logicielle . [1]

Les modifications sont généralement identifiées par un code numérique ou alphabétique, appelé « numéro de révision », « niveau de révision » ou simplement « révision ». Par exemple, un ensemble initial de fichiers est "révision 1". Lorsque la première modification est effectuée, l'ensemble résultant est "révision 2", et ainsi de suite. Chaque révision est associée à un horodatage et à la personne effectuant la modification. Les révisions peuvent être comparées, restaurées et, avec certains types de fichiers, fusionnées. [2]

Le besoin d'une manière logique d'organiser et de contrôler les révisions existe depuis presque aussi longtemps que l'écriture existe, mais le contrôle des révisions est devenu beaucoup plus important et compliqué lorsque l'ère de l'informatique a commencé. La numérotation des éditions de livres et des révisions de spécifications sont des exemples qui remontent à l'ère de l'imprimé uniquement. Aujourd'hui, les systèmes de contrôle de révision les plus performants (ainsi que les plus complexes) sont ceux utilisés dans le développement de logiciels , où une équipe de personnes peut simultanément apporter des modifications aux mêmes fichiers.

Les systèmes de contrôle de version sont le plus souvent exécutés en tant qu'applications autonomes, mais le contrôle de révision est également intégré à divers types de logiciels, tels que les traitements de texte et les tableurs , les documents Web collaboratifs , [3] et les systèmes de gestion de contenu , par exemple, l' historique des pages de Wikipedia . Le contrôle de révision permet de rétablir un document à une révision précédente, ce qui est essentiel pour permettre aux éditeurs de suivre les modifications des autres, de corriger les erreurs et de se défendre contre le vandalisme et le spam dans les wikis .

Vue d'ensemble

En génie logiciel , le contrôle des révisions est tout type de pratique qui permet de suivre et de contrôler les modifications apportées au code source . Les développeurs de logiciels utilisent parfois un logiciel de contrôle de révision pour conserver la documentation et les fichiers de configuration ainsi que le code source.

Lorsque les équipes conçoivent, développent et déploient des logiciels, il est courant que plusieurs versions du même logiciel soient déployées sur différents sites et que les développeurs du logiciel travaillent simultanément sur les mises à jour. Les bogues ou fonctionnalités du logiciel ne sont souvent présents que dans certaines versions (en raison de la résolution de certains problèmes et de l'introduction d'autres au fur et à mesure que le programme se développe). Par conséquent, dans le but de localiser et de corriger les bogues, il est extrêmement important de pouvoir récupérer et exécuter différentes versions du logiciel pour déterminer dans quelle(s) version(s) le problème se produit. Il peut également être nécessaire de développer simultanément deux versions du logiciel : par exemple, lorsqu'une version contient des bogues corrigés, mais aucune nouvelle fonctionnalité ( branche), tandis que l'autre version est celle où de nouvelles fonctionnalités sont travaillées ( trunk ).

Au niveau le plus simple, les développeurs pourraient simplement conserver plusieurs copies des différentes versions du programme et les étiqueter de manière appropriée. Cette approche simple a été utilisée dans de nombreux grands projets logiciels. Bien que cette méthode puisse fonctionner, elle est inefficace car de nombreuses copies quasi identiques du programme doivent être conservées. Cela demande beaucoup d'autodiscipline de la part des développeurs et conduit souvent à des erreurs. Étant donné que la base de code est la même, elle nécessite également d'accorder une autorisation de lecture-écriture-exécution à un ensemble de développeurs, ce qui ajoute la pression d'une personne gérant les autorisations afin que la base de code ne soit pas compromise, ce qui ajoute plus de complexité. Par conséquent, des systèmes pour automatiser tout ou partie du processus de contrôle de révision ont été développés. Cela garantit que la majorité de la gestion des étapes de contrôle de version est cachée dans les coulisses.

De plus, dans le développement de logiciels, la pratique juridique et commerciale et d'autres environnements, il est devenu de plus en plus courant qu'un seul document ou extrait de code soit édité par une équipe, dont les membres peuvent être dispersés géographiquement et peuvent poursuivre des activités différentes, voire contraires. intérêts. Un contrôle de révision sophistiqué qui suit et comptabilise la propriété des modifications apportées aux documents et au code peut être extrêmement utile, voire indispensable dans de telles situations.

Le contrôle des révisions peut également suivre les modifications apportées aux fichiers de configuration , tels que ceux généralement stockés dans /etcou /usr/local/etcsur les systèmes Unix. Cela donne aux administrateurs système un autre moyen de suivre facilement les modifications apportées et de revenir aux versions antérieures en cas de besoin.

Historique

L'outil de mise à jour logicielle OS/360 IEBUPDTE d'IBM remonte à 1962, sans doute un précurseur des outils du système de contrôle de version. Un système complet conçu pour le contrôle du code source a été lancé en 1972, le système de contrôle du code source pour le même système (OS / 360). L'introduction de Source Code Control System, publiée le 4 décembre 1975, impliquait historiquement qu'il s'agissait du premier système de contrôle de révision délibéré. [4] RCS a suivi juste après, [5] avec sa version en réseau Concurrent Versions System . La génération suivante après Concurrent Versions System a été dominée par Subversion , [6] suivi par la montée en puissance du contrôle de révision distribuédes outils tels que Git . [sept]

Structure

Le contrôle de révision gère les modifications apportées à un ensemble de données au fil du temps. Ces changements peuvent être structurés de différentes manières.

Souvent, les données sont considérées comme une collection de nombreux éléments individuels, tels que des fichiers ou des documents, et les modifications apportées aux fichiers individuels sont suivies. Cela concorde avec les intuitions concernant les fichiers séparés, mais pose des problèmes lorsque l'identité change, comme lors du changement de nom, du fractionnement ou de la fusion de fichiers. En conséquence, certains systèmes tels que Git , considèrent plutôt les modifications apportées aux données dans leur ensemble, ce qui est moins intuitif pour les modifications simples mais simplifie les modifications plus complexes.

Lorsque des données sous contrôle de révision sont modifiées, après avoir été récupérées par extraction , cela n'est généralement pas immédiatement reflété dans le système de contrôle de révision (dans le référentiel ), mais doit plutôt être archivé ou validé. Une copie en dehors du contrôle de révision est appelée "copie de travail". A titre d'exemple simple, lors de l'édition d'un fichier informatique, les données stockées en mémoire par le programme d'édition constituent la copie de travail, qui est validée par sauvegarde. Concrètement, on peut imprimer un document, le modifier à la main, et seulement plus tard saisir manuellement les modifications dans un ordinateur et le sauvegarder. Pour le contrôle du code source, la copie de travail est plutôt une copie de tous les fichiers d'une révision particulière, généralement stockée localement sur l'ordinateur du développeur ;[note 1] dans ce cas, l'enregistrement du fichier ne modifie que la copie de travail, et l'archivage dans le référentiel est une étape distincte.

Si plusieurs personnes travaillent sur un seul ensemble de données ou document, elles créent implicitement des branches de données (dans leurs copies de travail), et des problèmes de fusion se posent donc, comme indiqué ci-dessous. Pour une simple édition collaborative de documents, cela peut être évité en utilisant le verrouillage de fichiers ou en évitant simplement de travailler sur le même document sur lequel quelqu'un d'autre travaille.

Les systèmes de contrôle des révisions sont souvent centralisés, avec un seul magasin de données faisant autorité, le référentiel, et les extractions et les archivages sont effectués en référence à ce référentiel central. Alternativement, dans le contrôle de révision distribué , aucun référentiel unique ne fait autorité et les données peuvent être extraites et archivées dans n'importe quel référentiel. Lors de l'archivage dans un référentiel différent, cela est interprété comme une fusion ou un correctif.

Structure du graphique

Exemple de graphique d'historique d'un projet contrôlé par révision ; le tronc est en vert, les branches en jaune et le graphique n'est pas un arbre en raison de la présence de fusions (les flèches rouges).

En termes de théorie des graphes , les révisions sont généralement considérées comme une ligne de développement (le tronc ) avec des branches hors de celle-ci, formant un arbre dirigé, visualisé comme une ou plusieurs lignes parallèles de développement (les "lignes principales" des branches) se ramifiant hors d'un coffre. En réalité, la structure est plus compliquée, formant un graphe acyclique dirigé , mais à de nombreuses fins "arbre avec fusions" est une approximation adéquate.

Les révisions se produisent dans l'ordre au fil du temps et peuvent donc être organisées dans l'ordre, soit par numéro de révision, soit par horodatage. [note 2] Les révisions sont basées sur des révisions passées, bien qu'il soit possible de remplacer en grande partie ou complètement une révision antérieure, comme "supprimer tout le texte existant, insérer un nouveau texte". Dans le cas le plus simple, sans ramification ni annulation, chaque révision est basée uniquement sur son prédécesseur immédiat, et elles forment une ligne simple, avec une seule dernière version, la révision "HEAD" ou tip . En termes de théorie des graphes , en dessinant chaque révision comme un point et chaque relation de "révision dérivée" comme une flèche (pointant classiquement de l'ancien vers le plus récent, dans la même direction que le temps), il s'agit d'un graphique linéaire. S'il y a une ramification, donc plusieurs révisions futures sont basées sur une révision passée, ou une annulation, donc une révision peut dépendre d'une révision plus ancienne que son prédécesseur immédiat, alors le graphique résultant est à la place un arbre dirigé (chaque nœud peut avoir plus d'un enfant), et possède plusieurs astuces, correspondant aux révisions sans enfant ("dernière révision sur chaque branche"). [note 3] En principe, l'arborescence résultante n'a pas besoin d'avoir une astuce préférée ("principale" dernière révision) - juste diverses révisions différentes - mais en pratique une astuce est généralement identifiée comme HEAD. Lorsqu'une nouvelle révision est basée sur HEAD, elle est soit identifiée comme la nouvelle HEAD, soit considérée comme une nouvelle branche. [note 4]La liste des révisions du début à HEAD (en termes de théorie des graphes, le chemin unique dans l'arbre, qui forme un graphe linéaire comme auparavant) est le tronc ou la ligne principale. [note 5] Inversement, lorsqu'une révision peut être basée sur plus d'une révision précédente (lorsqu'un nœud peut avoir plus d'un parent ), le processus résultant est appelé une fusion et est l'un des aspects les plus complexes du contrôle de révision. Cela se produit le plus souvent lorsque des changements se produisent dans plusieurs branches (le plus souvent deux, mais plusieurs sont possibles), qui sont ensuite fusionnées en une seule branche incorporant les deux changements. Si ces modifications se chevauchent, il peut être difficile, voire impossible, de les fusionner et nécessiter une intervention manuelle ou une réécriture.

En présence de fusions, le graphe résultant n'est plus un arbre, car les nœuds peuvent avoir plusieurs parents, mais plutôt un graphe acyclique dirigé (DAG) enraciné. Le graphique est acyclique car les parents sont toujours en arrière dans le temps, et enraciné car il existe une version la plus ancienne. En supposant qu'il y ait un tronc, les fusions des branches peuvent être considérées comme "externes" à l'arborescence - les modifications dans la branche sont regroupées sous la forme d'un patch, qui est appliqué à HEAD (du tronc), créant une nouvelle révision sans aucun explicite référence à la branche, et en préservant l'arborescence. Ainsi, alors que les relations réelles entre les versions forment un DAG, cela peut être considéré comme un arbre plus des fusions, et le tronc lui-même est une ligne.

Dans le contrôle de révision distribué, en présence de plusieurs référentiels, ceux-ci peuvent être basés sur une seule version originale (une racine de l'arborescence), mais il n'est pas nécessaire qu'il y ait une racine d'origine, et donc seulement une racine distincte (révision la plus ancienne) pour chaque référentiel , par exemple, si deux personnes commencent à travailler sur un projet séparément. De même, en présence de plusieurs ensembles de données (plusieurs projets) qui échangent des données ou fusionnent, il n'y a pas de racine unique, bien que pour simplifier, on puisse considérer un projet comme principal et l'autre comme secondaire, fusionné dans le premier avec ou sans son propre historique de révision.

Stratégies spécialisées

Contrôle de révision d'ingénierie développé à partir de processus formalisés basés sur le suivi des révisions des premiers plans ou lignes bleues [ citation nécessaire ] . Ce système de contrôle permettait implicitement de revenir à un état antérieur de la conception, pour les cas où une impasse technique était atteinte dans le développement de la conception. Une table de révision a été utilisée pour garder une trace des modifications apportées. De plus, les zones modifiées du dessin ont été mises en évidence à l'aide de nuages ​​de révision.

Le contrôle de version est répandu dans les affaires et le droit. En effet, la « ligne rouge contractuelle » et la « ligne noire juridique » sont parmi les premières formes de contrôle de révision, [8] et sont toujours employées dans les affaires et le droit avec des degrés de sophistication variables. Les techniques les plus sophistiquées commencent à être utilisées pour le suivi électronique des modifications des fichiers CAO (voir gestion des données produit ), supplantant la mise en œuvre électronique "manuelle" du contrôle de révision traditionnel. [ citation nécessaire ]

Modèles de gestion des sources

Les systèmes de contrôle de révision traditionnels utilisent un modèle centralisé où toutes les fonctions de contrôle de révision ont lieu sur un serveur partagé . Si deux développeurs essaient de modifier le même fichier en même temps, sans aucune méthode de gestion de l'accès, les développeurs peuvent finir par écraser le travail de l'autre. Les systèmes de contrôle de révision centralisés résolvent ce problème dans l'un des deux "modèles de gestion des sources" différents : le verrouillage des fichiers et la fusion des versions.

Opérations atomiques

Une opération est atomique si le système est laissé dans un état cohérent même si l'opération est interrompue. L' opération de validation est généralement la plus critique dans ce sens. Les commits indiquent au système de contrôle de révision de rendre un groupe de modifications final et disponible pour tous les utilisateurs. Tous les systèmes de contrôle de révision n'ont pas de commits atomiques ; Le système de versions simultanées ne dispose pas de cette fonctionnalité. [9]

Verrouillage de fichiers

La méthode la plus simple pour éviter les problèmes d'« accès simultanés » consiste à verrouiller les fichiers afin qu'un seul développeur à la fois ait accès en écriture aux copies du « référentiel » central de ces fichiers. Une fois qu'un développeur "extrait" un fichier, d'autres peuvent lire ce fichier, mais personne d'autre ne peut modifier ce fichier jusqu'à ce que ce développeur "archive" la version mise à jour (ou annule l'extraction).

Le verrouillage des fichiers présente à la fois des avantages et des inconvénients. Il peut fournir une certaine protection contre les conflits de fusion difficiles lorsqu'un utilisateur apporte des modifications radicales à de nombreuses sections d'un fichier (ou d'un groupe de fichiers) volumineux. Si les fichiers sont laissés exclusivement verrouillés pendant trop longtemps, d'autres développeurs peuvent être tentés de contourner le logiciel de contrôle de révision et de modifier les fichiers localement, forçant une fusion manuelle difficile lorsque les autres modifications sont finalement archivées. Dans une grande organisation, les fichiers peuvent être laissé "extrait" et verrouillé et oublié au fur et à mesure que les développeurs se déplacent entre les projets - ces outils peuvent ou non permettre de voir facilement qui a extrait un fichier.

Fusion de versions

La plupart des systèmes de contrôle de version permettent à plusieurs développeurs de modifier le même fichier en même temps. Le premier développeur à "enregistrer" les modifications dans le référentiel central réussit toujours. Le système peut fournir des fonctionnalités pour fusionner d' autres modifications dans le référentiel central et conserver les modifications du premier développeur lorsque d'autres développeurs s'enregistrent.

La fusion de deux fichiers peut être une opération très délicate, et généralement possible uniquement si la structure des données est simple, comme dans les fichiers texte . Le résultat d'une fusion de deux fichiers image peut ne pas aboutir à un fichier image du tout. Le deuxième développeur vérifiant le code devra faire attention à la fusion, pour s'assurer que les modifications sont compatibles et que l'opération de fusion n'introduit pas ses propres erreurs logiques dans les fichiers. Ces problèmes limitent la disponibilité des opérations de fusion automatiques ou semi-automatiques principalement à de simples documents textuels, à moins qu'un plug -in de fusion spécifique ne soit disponible pour les types de fichiers.

Le concept d' édition réservée peut fournir un moyen facultatif de verrouiller explicitement un fichier pour un accès exclusif en écriture, même lorsqu'une capacité de fusion existe.

Lignes de base, étiquettes et balises

La plupart des outils de contrôle de révision n'utiliseront qu'un seul de ces termes similaires (baseline, label, tag) pour désigner l'action d'identification d'un instantané ("label the project") ou l'enregistrement de l'instantané ("try it with baseline X ") . Généralement, un seul des termes ligne de base , étiquette ou étiquette est utilisé dans la documentation ou la discussion [ citation nécessaire ] ; ils peuvent être considérés comme des synonymes.

Dans la plupart des projets, certains instantanés sont plus significatifs que d'autres, tels que ceux utilisés pour indiquer les versions publiées, les branches ou les jalons.

Lorsque le terme ligne de base et l' étiquette ou l'étiquette sont utilisés ensemble dans le même contexte, l' étiquette et l'étiquette font généralement référence au mécanisme au sein de l'outil d'identification ou d'enregistrement de l'instantané, et la ligne de base indique l'importance accrue d'une étiquette donnée . ou balise.

La plupart des discussions formelles sur la gestion de la configuration utilisent le terme baseline .

Contrôle de révision distribué

Les systèmes de contrôle de révision distribués (DRCS) adoptent une approche peer-to-peer, par opposition à l' approche client-serveur des systèmes centralisés. Plutôt qu'un référentiel central unique sur lequel les clients se synchronisent, la copie de travail de la base de code de chaque pair est un référentiel authentique . [10] Le contrôle de révision distribué effectue la synchronisation en échangeant des correctifs (ensembles de modifications) d'un homologue à l'autre. Il en résulte des différences importantes par rapport à un système centralisé :

  • Aucune copie de référence canonique de la base de code n'existe par défaut ; uniquement des copies de travail.
  • Les opérations courantes (telles que les validations, l'affichage de l'historique et l'annulation des modifications) sont rapides, car il n'est pas nécessaire de communiquer avec un serveur central. [1] : 7 

Au contraire, la communication n'est nécessaire que pour pousser ou tirer des modifications vers ou depuis d'autres pairs.

  • Chaque copie de travail fonctionne efficacement comme une sauvegarde à distance de la base de code et de son historique des modifications, offrant une protection inhérente contre la perte de données. [1] : 4 

Intégration

Certains des outils de contrôle de révision les plus avancés offrent de nombreuses autres fonctionnalités, permettant une intégration plus approfondie avec d'autres outils et processus d'ingénierie logicielle. Des plugins sont souvent disponibles pour les IDE tels que Oracle JDeveloper , IntelliJ IDEA , Eclipse , Visual Studio , Delphi , NetBeans IDE , Xcode et GNU Emacs (via vc.el). Les prototypes de recherche avancée génèrent des messages de validation appropriés [11] , mais cela ne fonctionne que sur des projets qui ont déjà un historique important, car les messages de validation dépendent fortement des conventions et des idiosyncrasies du projet.[12]

Terminologie commune

La terminologie peut varier d'un système à l'autre, mais certains termes d'usage courant incluent : [13]

Ligne de base
Une révision approuvée d'un document ou d'un fichier source auquel des modifications ultérieures peuvent être apportées. Voir les lignes de base, les étiquettes et les balises .
Faire des reproches
Une recherche de l'auteur et de la révision qui a modifié en dernier une ligne particulière.
Bifurquer
Un ensemble de fichiers sous contrôle de version peut être ramifié ou bifurqué à un moment donné de sorte qu'à partir de ce moment, deux copies de ces fichiers peuvent se développer à des vitesses différentes ou de différentes manières indépendamment l'une de l'autre.
Changer
Un changement (ou diff , ou delta ) représente une modification spécifique d'un document sous contrôle de version. La granularité de la modification considérée comme un changement varie selon les systèmes de contrôle de version.
Modifier la liste
Sur de nombreux systèmes de contrôle de version avec des validations atomiques à modifications multiples, une liste de modifications (ou CL ), un ensemble de modifications , une mise à jour ou un correctif identifie l'ensemble des modifications apportées dans une seule validation. Cela peut également représenter une vue séquentielle du code source, permettant l'examen de la source à partir de n'importe quel ID de liste de modifications particulier.
Vérifier
Extraire (ou co ) consiste à créer une copie de travail locale à partir du référentiel . Un utilisateur peut spécifier une révision spécifique ou obtenir la dernière. Le terme « paiement » peut également être utilisé comme nom pour décrire la copie de travail. Lorsqu'un fichier a été extrait d'un serveur de fichiers partagé, il ne peut pas être modifié par d'autres utilisateurs. Considérez-le comme un hôtel, lorsque vous partez, vous n'avez plus accès à ses commodités.
Cloner
Le clonage consiste à créer un dépôt contenant les révisions d'un autre dépôt. Cela équivaut à pousser ou à tirer dans un référentiel vide (nouvellement initialisé). En tant que nom, deux référentiels peuvent être considérés comme des clones s'ils sont maintenus synchronisés et contiennent les mêmes révisions.
Commettre (nom masculin)
Un 'commit' ou 'revision' (SVN) est une modification qui est appliquée au référentiel.
Commettre (verbe)
Commettre ( archiver , ci ou , plus rarement, installer , soumettre ou enregistrer ) consiste à écrire ou à fusionner les modifications apportées à la copie de travail dans le référentiel. Une validation contient des métadonnées, généralement les informations sur l'auteur et un message de validation décrivant la modification.
Conflit
Un conflit se produit lorsque différentes parties apportent des modifications au même document et que le système est incapable de concilier les modifications. Un utilisateur doit résoudre le conflit en combinant les modifications ou en sélectionnant une modification en faveur de l'autre.
Compression delta
La plupart des logiciels de contrôle de révision utilisent la compression delta , qui ne conserve que les différences entre les versions successives des fichiers. Cela permet un stockage plus efficace de nombreuses versions différentes de fichiers.
Flux dynamique
Un flux dans lequel certaines ou toutes les versions de fichiers sont des miroirs des versions du flux parent.
Exporter
L' exportation est l'acte d'obtenir les fichiers du référentiel. Il est similaire à l' extraction, sauf qu'il crée une arborescence de répertoires propre sans les métadonnées de contrôle de version utilisées dans une copie de travail. Ceci est souvent utilisé avant la publication du contenu, par exemple.
Aller chercher
Voir tirer .
Intégration en aval
Processus de fusion des modifications apportées au tronc principal dans une branche de développement (fonctionnalité ou équipe).
Tête
Aussi parfois appelé tip , cela fait référence au commit le plus récent, soit sur le tronc, soit sur une branche. Le tronc et chaque branche ont leur propre tête, bien que HEAD soit parfois vaguement utilisé pour désigner le tronc. [14]
Importer
L'importation consiste à copier une arborescence de répertoires locaux (qui n'est actuellement pas une copie de travail) dans le référentiel pour la première fois.
Initialiser
Pour créer un nouveau référentiel vide.
Deltas entrelacés
Certains logiciels de contrôle de révision utilisent des deltas entrelacés , une méthode qui permet de stocker l'historique des fichiers texte d'une manière plus efficace qu'en utilisant la compression Delta .
Étiquette
Voir balise .
Verrouillage
Lorsqu'un développeur verrouille un fichier, personne d'autre ne peut mettre à jour ce fichier tant qu'il n'est pas déverrouillé. Le verrouillage peut être pris en charge par le système de contrôle de version ou via des communications informelles entre développeurs (c'est- à-dire le verrouillage social ).
Ligne principale
Semblable à trunk , mais il peut y avoir une ligne principale pour chaque branche.
Fusionner
Une fusion ou une intégration est une opération dans laquelle deux ensembles de modifications sont appliqués à un fichier ou à un ensemble de fichiers. Voici quelques exemples de scénarios :
  • Un utilisateur, travaillant sur un ensemble de fichiers, met à jour ou synchronise sa copie de travail avec les modifications apportées et archivées dans le référentiel par d'autres utilisateurs. [15]
  • Un utilisateur essaie d' archiver des fichiers qui ont été mis à jour par d'autres depuis qu'ils ont été extraits , et le logiciel de contrôle de révision fusionne automatiquement les fichiers (généralement, après avoir demandé à l'utilisateur s'il doit procéder à la fusion automatique, et dans certains cas uniquement le faire si la fusion peut être clairement et raisonnablement résolue).
  • Une branche est créée, le code dans les fichiers est modifié de manière indépendante et la branche mise à jour est ensuite incorporée dans un tronc unique et unifié .
  • Un ensemble de fichiers est ramifié , un problème qui existait avant la ramification est résolu dans une branche, et le correctif est ensuite fusionné dans l'autre branche. (Ce type de fusion sélective est parfois connu sous le nom de picorage pour le distinguer de la fusion complète dans le cas précédent.)
Promouvoir
Action de copier le contenu d'un fichier d'un emplacement moins contrôlé vers un emplacement plus contrôlé. Par exemple, depuis l'espace de travail d'un utilisateur vers un référentiel, ou depuis un flux vers son parent. [16]
Tirez, poussez
Copiez les révisions d'un dépôt dans un autre. Le pull est initié par le référentiel de réception, tandis que le push est initié par la source. Fetch est parfois utilisé comme synonyme de pull , ou pour désigner un pull suivi d'une mise à jour .
Demande d'extraction
Un développeur demandant aux autres de fusionner leurs modifications "poussées".
Dépôt
Le référentiel (ou "repo") est l'endroit où les données actuelles et historiques des fichiers sont stockées, souvent sur un serveur. Parfois aussi appelé dépôt .
Résoudre
Action d'intervention de l'utilisateur pour résoudre un conflit entre différentes modifications apportées au même document.
Intégration inversée
Processus de fusion de différentes branches d'équipe dans le tronc principal du système de gestion des versions.
Révision
Aussi version : Une version est tout changement de forme. Dans SVK, une révision est l'état à un moment donné de l'arborescence entière dans le référentiel.
Partager
Action de rendre un fichier ou un dossier disponible dans plusieurs succursales en même temps. Lorsqu'un fichier partagé est modifié dans une branche, il est modifié dans les autres branches.
Flux
Un conteneur pour les fichiers ramifiés qui a une relation connue avec d'autres conteneurs de ce type. Les flux forment une hiérarchie ; chaque flux peut hériter de diverses propriétés (telles que les versions, l'espace de noms, les règles de workflow, les abonnés, etc.) de son flux parent.
Étiquette
Une balise ou une étiquette fait référence à un instantané important dans le temps, cohérent dans de nombreux fichiers. Ces fichiers à ce stade peuvent tous être étiquetés avec un nom ou un numéro de révision convivial et significatif. Voir les lignes de base, les étiquettes et les balises .
Tronc
L'unique ligne de développement qui n'est pas une branche (parfois aussi appelée Baseline, Mainline ou Master [17] [18] )
Mise à jour
Une mise à jour (ou sync , mais sync peut également signifier un push et un pull combinés ) fusionne les modifications apportées au référentiel (par d'autres personnes, par exemple) dans la copie de travail locale . La mise à jour est également le terme utilisé par certains outils CM (CM+, PLS, SMS) pour le concept de package de modifications (voir la liste des modifications ). Synonyme de vérification dans les systèmes de contrôle de révision qui exigent que chaque référentiel ait exactement une copie de travail (courant dans les systèmes distribués)
Déverrouillage
libérer un verrou.
Copie de travail
La copie de travail est la copie locale des fichiers d'un référentiel, à un moment ou à une révision spécifique. Tout le travail effectué sur les fichiers d'un référentiel est initialement effectué sur une copie de travail, d'où son nom. Conceptuellement, il s'agit d'un bac à sable .

Voir aussi

Remarques

  1. ^ Dans ce cas, les tampons d'édition sont une forme secondaire de copie de travail et ne sont pas référencés comme tels.
  2. ^ En principe, deux révisions peuvent avoir un horodatage identique et ne peuvent donc pas être commandées sur une ligne. C'est généralement le cas pour des référentiels séparés, mais c'est également possible pour des modifications simultanées de plusieurs branches dans un même référentiel. Dans ces cas, les révisions peuvent être considérées comme un ensemble de lignes distinctes, une par référentiel ou branche (ou branche au sein d'un référentiel).
  3. ^ L '«arborescence» de révision ou de référentiel ne doit pas être confondue avec l'arborescence de répertoires de fichiers dans une copie de travail.
  4. ^ Notez que si une nouvelle branche est basée sur HEAD, alors topologiquement HEAD n'est plus une pointe, car elle a un enfant.
  5. ^ "Mainline" peut également faire référence au chemin principal dans une branche distincte.

Références

  1. ^ un bc O'Sullivan , Bryan (2009). Mercurial : le guide définitif . Sébastopol : O'Reilly Media, Inc. ISBN 9780596555474. Récupéré le 4 septembre 2015 .
  2. ^ Scott, Chacon; Straub, Ben (2014). Pro Git deuxième édition . États-Unis : Apress . p. 14.
  3. ^ " Google Docs ", Voir ce qui a changé dans un fichier , Google Inc..
  4. ^ Rochkind, Marc J. (1975). "Le système de contrôle du code source" (PDF) . Transactions IEEE sur le génie logiciel . SE-1 (4): 364–370. doi : 10.1109/TSE.1975.6312866 . S2CID 10006076 .  
  5. ^ Tichy, Walter F. (1985). "RCS — un système de contrôle de version" . Logiciel : pratique et expérience . 15 (7): 637–654. doi : 10.1002/spe.4380150703 . ISSN 0038-0644 . S2CID 2605086 .  
  6. ^ Collins-Sussman, Ben; Fitzpatrick, BW; Pilato, CM (2004), Contrôle de version avec Subversion , O'Reilly, ISBN 0-596-00448-6
  7. ^ Loeliger, Jon; McCullough, Matthieu (2012). Contrôle de version avec Git : outils et techniques puissants pour le développement collaboratif de logiciels . O'Reilly Media. p. 2–5. ISBN 9781449345044.
  8. Pour les dessins techniques, voir Whiteprint#Document control , pour certains des systèmes manuels en place au XXe siècle, par exemple, les Engineering Procedures of Hughes Aircraft , dont chaque révision nécessitait l'approbation de Lawrence A. Hyland ; voir aussi les procédures d'approbation instituées par le gouvernement américain.
  9. ^ Intelligent, John Ferguson (2008). Outils électriques Java . "O'Reilly Media, Inc.". p. 301.ISBN _ 9781491954546. Récupéré le 20 juillet 2019 .
  10. ^ Wheeler, David. "Commentaires sur les systèmes de gestion de la configuration logicielle (SCM) des logiciels open source / logiciels libres (OSS / FS)" . Archivé de l'original le 9 novembre 2020 . Récupéré le 8 mai 2007 .
  11. ^ Cortes-Coy, Luis Fernando; Linares-Vasquez, Mario; Aponte, Jairo ; Poshyvanyk, Denys (2014). "Sur la génération automatique de messages de validation via la synthèse des modifications du code source". 2014 IEEE 14e Conférence de travail internationale sur l'analyse et la manipulation de code source . IEEE. p. 275–284. doi : 10.1109/arnaque.2014.14 . ISBN 978-1-4799-6148-1. S2CID  360545 .
  12. ^ Etemadi, Khashayar; Monperrus, Martin (2020-06-27). "Sur la pertinence de l'apprentissage inter-projets avec les voisins les plus proches pour la génération de messages de validation". Actes de la 42e conférence internationale IEEE / ACM sur les ateliers de génie logiciel . Séoul, République de Corée : ACM. p. 470–475. arXiv : 2010.01924 . doi : 10.1145/3387940.3391488 . ISBN 9781450379632. S2CID  221911386 .
  13. ^ Wingerd, Laura (2005). Force pratique . O'Reilly. ISBN 0-596-10185-6. Archivé de l'original le 2007-12-21 . Récupéré le 27/08/2006 .
  14. ^ Grégory, Gary (3 février 2011). "Trunk vs HEAD dans les systèmes de contrôle de version" . Java, Eclipse et d'autres informations techniques . Récupéré le 16/12/2012 .
  15. ^ Collins-Sussman, Fitzpatrick & Pilato 2004 , 1.5: résolution du cycle de tournée SVN : 'Le G signifie merGed, ce qui signifie que le fichier avait des changements locaux pour commencer, mais les changements provenant du référentiel ne se chevauchaient pas avec le local changements.'
  16. ^ Manuel des concepts (version 4.7 éd.). Précis. juillet 2008.
  17. ^ Wallen, Jack (2020-09-22). "GitHub remplacera master par main à partir d'octobre : ce que les développeurs doivent faire maintenant" . TechRepublic . Récupéré le 24/04/2022 .
  18. ^ Heinze, Carolyn (2020-11-24). "Pourquoi GitHub a renommé sa branche master en main" . LeCôtéServeur . Récupéré le 24/04/2022 .

Liens externes

  • "Guide visuel du contrôle de version", mieux expliqué.
  • Sink, Eric, "Contrôle de la source", SCM (comment faire). Les bases du contrôle de version.