Contrôle de version - Version control

En génie logiciel , contrôle de version (également connue sous le nom de contrôle de révision , le contrôle des sources , ou la gestion de code source ) est une classe de systèmes chargés de gérer les changements de programmes informatiques , des documents, des grands sites Web ou d' autres collections d'informations. Le contrôle de version est un composant de la gestion de configuration logicielle .

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 qui effectue la modification. Les révisions peuvent être comparées, restaurées et fusionnées avec certains types de fichiers.

Le besoin d'un moyen 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'impression 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 ( VCS ) 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 et divers systèmes de gestion de contenu , par exemple l' historique des pages de Wikipédia . Le contrôle des révisions permet de revenir à une révision précédente d'un document, ce qui est essentiel pour permettre aux éditeurs de suivre les modifications des uns et des autres, de corriger les erreurs et de se défendre contre le vandalisme et le spam dans les wikis .

Aperçu

En génie logiciel informatique , le contrôle de révision 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.

Au fur et à mesure que 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 bugs 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 du développement du programme). 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 deux versions du logiciel simultanément : par exemple, où une version a des bogues corrigés, mais aucune nouvelle fonctionnalité ( branche ), tandis que l'autre version est celle où de nouvelles fonctionnalités sont travaillées ( tronc ).

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, cela nécessite également d'accorder une autorisation de lecture-écriture-exécution à un ensemble de développeurs, ce qui ajoute la pression de quelqu'un qui gère 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 un seul extrait de code soit édité par une équipe, dont les membres peuvent être géographiquement dispersés et poursuivre des activités différentes et même contraires. intérêts. Un contrôle de révision sophistiqué qui suit et prend en compte 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 de révision 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 un moyen de revenir aux versions antérieures en cas de besoin.

Histoire

L' outil de mise à jour du logiciel OS/360 IEBUPDTE d' IBM remonte à 1962, sans doute un précurseur des outils VCS. Un système complet conçu pour le contrôle du code source a été lancé en 1972, SCCS pour le même système (OS/360). L'introduction du SCCS, ayant été 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é. RCS a suivi juste après, avec sa version en réseau CVS. La génération suivante après CVS a été dominée par Subversion , suivie par la montée en puissance des outils de contrôle de révision distribués tels que Git .

Structure

Le contrôle des révisions gère les modifications apportées à un ensemble de données au fil du temps. Ces changements peuvent être structurés de diverses 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, de la division 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 à la place ê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 sont la copie de travail, qui est validée par la sauvegarde. Concrètement, on peut imprimer un document, l'éditer à la main, et seulement plus tard saisir manuellement les modifications dans un ordinateur et l'enregistrer. 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 ; 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 des données (dans leurs copies de travail), et donc des problèmes de fusion se posent, comme indiqué ci-dessous. Pour une simple édition collaborative de documents, cela peut être évité en utilisant le verrouillage de fichier ou en évitant simplement de travailler sur le même document que celui 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 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 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, formant un arbre orienté, visualisé comme une ou plusieurs lignes de développement parallèles (les "lignes principales" des branches) hors d'un coffre. En réalité, la structure est plus compliquée, formant un graphe acyclique orienté , mais pour de nombreux objectifs, "l'arbre avec fusions" est une approximation adéquate.

Les révisions se produisent en séquence dans le temps et peuvent donc être classées dans l'ordre, soit par numéro de révision, soit par horodatage. Les révisions sont basées sur les révisions passées, bien qu'il soit possible de remplacer en grande partie ou complètement une révision antérieure, telle que "supprimer tout le texte existant, insérer un nouveau texte". Dans le cas le plus simple, sans branchement 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 ou astuce "HEAD" . En termes de théorie des graphes , dessinant chaque révision sous la forme d'un point et chaque relation de « révision dérivée » sous la forme d'une flèche (pointant classiquement de l'ancienne vers la plus récente, dans la même direction que le temps), il s'agit d'un graphique linéaire . S'il y a un branchement, de sorte que plusieurs révisions futures sont basées sur une révision passée, ou une annulation, de sorte qu'une révision peut dépendre d'une révision plus ancienne que son prédécesseur immédiat, alors le graphe résultant est plutôt un arbre dirigé (chaque nœud peut avoir plus d'un child), et possède plusieurs astuces, correspondant aux révisions sans enfants ("dernière révision sur chaque branche"). En principe, l'arbre résultant n'a pas besoin d'avoir une astuce préférée (dernière révision "principale") - juste plusieurs 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. La liste des révisions depuis le début de HEAD (en termes de théorie des graphes, le chemin unique dans l'arbre, qui forme un graphe linéaire comme avant) est le tronc ou la ligne principale. A l' inverse, quand une révision peut être basée sur plus d'une version précédente (quand un noeud peut avoir plus d'un parent ), le processus résultant est appelé une opération de fusion , et est l' un des aspects les plus complexes de contrôle de révision. Cela se produit le plus souvent lorsque des modifications se produisent dans plusieurs branches (le plus souvent deux, mais plus sont possibles), qui sont ensuite fusionnées en une seule branche incorporant les deux modifications. Si ces changements se chevauchent, il peut être difficile ou 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 est plutôt un graphe acyclique dirigé enraciné (DAG). Le graphe est acyclique puisque les parents sont toujours en arrière dans le temps, et enraciné car il existe une version la plus ancienne. Cependant, en supposant qu'il y ait un tronc, les fusions de branches peuvent être considérées comme "externes" à l'arbre - les changements dans la branche sont regroupés sous forme de patch, qui est appliqué à HEAD (du tronc), créant une nouvelle révision sans référence explicite à 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 d'origine (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 (la plus ancienne révision) pour chaque référentiel , par exemple, si deux personnes commencent à travailler séparément sur un projet. 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 une seule racine, bien que pour plus de simplicité, 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 des processus d' ingénierie développé formalisés sur la base de suivi des révisions des plans précoces ou bluelines . 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 du contrat » et la « ligne noire légale » sont quelques-unes des premières formes de contrôle des révisions et sont toujours utilisées dans les affaires et le droit avec des degrés divers de sophistication. Les techniques les plus sophistiquées commencent à être utilisées pour le suivi électronique des modifications des fichiers CAO (voir gestion des données produits ), supplantant la mise en œuvre électronique "manuelle" du contrôle de révision traditionnel.

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 une méthode de gestion des 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 ; notamment, CVS n'a pas cette fonctionnalité.

Verrouillage de fichiers

La méthode la plus simple pour empêcher les problèmes d'« accès concurrent » consiste à verrouiller les fichiers de sorte qu'un seul développeur à la fois ait un 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 "enregistre" la version mise à jour (ou annule l'extraction).

Le verrouillage de fichiers a à 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 volumineux (ou d'un groupe de fichiers). Cependant, 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 enregistrées. Dans une grande organisation, les fichiers peuvent être laissés « extraits » et verrouillés et oubliés lorsque 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 à « archiver » 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 préserver 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 du tout aboutir à un fichier image. Le deuxième développeur qui vérifie le code devra faire attention à la fusion, 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 aux documents textuels simples, à moins qu'un plug - in de fusion spécifique ne soit disponible pour les types de fichiers.

Le concept d'une modification 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é ("étiqueter le projet") ou l'enregistrement de l'instantané ("essayez-le avec la ligne de base X ") . Généralement, un seul des termes ligne de base , étiquette ou balise est utilisé dans la documentation ou la discussion ; ils peuvent être considérés comme des synonymes.

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

Lorsque le terme de référence et l'un ou l'autre d' étiquette ou d' étiquette sont utilisés ensemble dans le même contexte, étiquette et é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 référence indique l'importance accrue d'une étiquette donnée ou étiquette.

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

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 de bonne foi . Le contrôle de révision distribué effectue la synchronisation en échangeant des correctifs (ensembles de modifications) d'égal à égal. 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 exemplaires 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.

Au contraire, la communication n'est nécessaire que pour pousser ou extraire des changements vers ou en provenance 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.

L'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 poussée 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 et 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, mais cela ne fonctionne que sur des projets ayant déjà un historique important, car les messages de validation dépendent beaucoup des conventions et des particularités du projet.

Terminologie courante

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

Référence

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 ont modifié en dernier une ligne particulière.

Branche

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 puissent se développer à des vitesses différentes ou de manières différentes 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 commits multi-changements atomiques , une liste de modifications (ou CL ), un ensemble de modifications , une mise à jour ou un correctif identifie l'ensemble des modifications apportées dans un seul commit. Cela peut également représenter une vue séquentielle du code source, permettant l'examen de la source comme de tout ID de liste de modifications particulier.

Vérifier

Pour vérifier (ou co ) est de créer une copie locale du référentiel. Un utilisateur peut spécifier une révision spécifique ou obtenir la dernière. Le terme « checkout » 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. Pensez-y comme à un hôtel, lors de votre départ, vous n'avez plus accès à ses commodités.

Cloner

Le clonage signifie créer un référentiel contenant les révisions d'un autre référentiel. 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.

s'engager (nom)

Un 'commit' ou 'revision' (SVN) est une modification qui est appliquée au référentiel.

S'engager (verbe)

Pour engager ( chèque , ci ou, plus rarement, installer , soumettre ou enregistrement ) est d'écrire ou de 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 rapprocher 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

Flux dans lequel certaines ou toutes les versions de fichiers sont des miroirs des versions du flux parent.

Exportation

l'exportation est l'acte d'obtenir les fichiers du référentiel. C'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

Le processus de fusion des modifications apportées dans le tronc principal dans une branche de développement (fonctionnalité ou équipe).

Diriger

Aussi parfois appelé tip , cela fait référence au commit le plus récent, soit vers le tronc, soit vers une branche. Le tronc et chaque branche ont leur propre tête, bien que HEAD soit parfois vaguement utilisé pour désigner le tronc.

Importer

l'importation consiste à copier pour la première fois une arborescence de répertoires locaux (qui n'est pas actuellement une copie de travail) dans le référentiel.

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 .

Étiqueter

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 (également appelée verrouillage social ).

Ligne principale

Similaire au tronc , 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.
Un utilisateur essaie d' archiver des fichiers qui ont été mis à jour par d'autres depuis que les fichiers 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 résolue de manière claire et raisonnable).
Une branche est créée, le code dans les fichiers est édité indépendamment 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 que le branchement soit 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 pioche 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.
Tirez, poussez: Copiez les révisions d'un référentiel dans un autre. Pull est initié par le référentiel de réception, tandis que push est initié par la source. Fetch est parfois utilisé comme synonyme de pull , ou pour signifier un pull suivi d' une mise à jour .
Demande de tirage: 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: L'acte d'intervention de l'utilisateur pour résoudre un conflit entre différentes modifications apportées au même document.
Intégration inverse: Le processus de fusion de différentes branches d'équipe dans le tronc principal du système de gestion des versions.
Révision: Version aussi : 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 branches 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.
Étiqueter: Une balise ou une étiquette fait référence à un instantané important dans le temps, cohérent sur 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: La ligne de développement unique qui n'est pas une branche (parfois aussi appelée Baseline, Mainline ou Master)
Mettre à jour: Une mise à jour (ou sync , mais sync peut également signifier un push et pull combiné ) fusionne les modifications apportées dans le référentiel (par d'autres personnes, par exemple) dans la copie de travail locale . Mise à jour est également le terme utilisé par certains outils CM (CM +, PLS, SMS) pour le concept de package de changement (voir changelist ). Synonyme d' extraction dans les systèmes de contrôle de révision qui exigent que chaque référentiel ait exactement une copie de travail (commune dans les systèmes distribués)
Déverrouillage: débloquer 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ù le nom. Conceptuellement, c'est un bac à sable .

Voir également

Remarques

Les références

Liens externes

"Guide visuel du contrôle de version", Mieux expliqué.
Sink, Eric, "Source Control", SCM (mode d'emploi). Les bases du contrôle de version.

Languages

In other projects