Contrôle de version: pourquoi vous ne pouvez pas vous en passer

Si vous utilisez un ordinateur, vous avez probablement été confronté au problème de différentes versions de fichiers. Qu’il s’agisse de fichiers texte, de fichiers de données ou de code de programme que vous avez écrits, vous serez toujours confronté à la décision de sauvegarder et de remplacer la version précédente ou de sauvegarder en plus de la version précédente.

Pour les développeurs uniques, il est déjà difficile de garder une trace des différentes versions d’un programme, sans parler de toutes les différentes sauvegardes que vous pourriez faire.

Imaginez maintenant que vous travaillez au sein d’une équipe sur un projet qui implique du texte, du multimédia et du codage – bref, une grande variété d’informations en préparation.

Imaginez plus loin: supposons que chaque fichier de données ou de programme soit travaillé par plusieurs personnes («simultanéité») – chaque personne ajoutant, enregistrant, éditant et enregistrant à nouveau. Comment diable saurez-vous qui a fait quoi, quand et pourquoi et pourrez-vous suivre tous ces changements??

Vous avez besoin du contrôle de version (VC).

Dans cet article, nous allons voir ce qu’est le contrôle de version et comment il a évolué au fil des ans jusqu’à la dernière génération..

En particulier, nous allons examiner Git, l’application de contrôle de version de plus en plus populaire des personnes qui ont créé Linux, et voir quelques exemples de la façon dont vous utiliseriez Git pour reprendre le contrôle de toutes ces différentes révisions de vos fichiers.

Une introduction au jargon VC

Le contrôle de version a sa propre langue. Après avoir spécifié les répertoires ou groupes de fichiers dont les modifications doivent être suivies est connue, les répertoires ou fichiers sont appelés référentiel ou référentiel.

Les modifications sont suivies automatiquement, mais elles ne sont enregistrées que comme une seule collection d’actions, appelée validation, et enregistrées comme un ensemble de modifications avec un numéro de révision unique. Cela garantit que vous pouvez appeler la dernière version d’un fichier.

Si vous souhaitez comparer deux révisions (par exemple, si un bogue s’est glissé dans votre code à un moment donné), l’outil de contrôle de version devrait vous permettre de différencier deux fichiers, ce qui signifie voir les différences entre les deux.

Pour expérimenter un dépôt sans risquer de problèmes ou de dommages, vous pouvez créer une branche, c’est-à-dire une copie du dépôt, que vous pouvez ensuite modifier en parallèle. Si les changements dans la branche sont satisfaisants, vous pouvez alors fusionner la branche avec le référentiel principal (maître), ou même une autre branche.

Lors de la fusion, les systèmes de contrôle de version modernes sont généralement assez intelligents pour déterminer quels changements doivent être inclus à partir de quelle branche ou dépôt, en fonction de l’historique des changements conservé pour chacun. Si un système de contrôle de version ne peut pas décider, vous devrez peut-être résoudre manuellement un conflit.

Évolution des systèmes de contrôle de version

Les outils de contrôle de version sont apparus jusqu’à présent sur trois générations, chaque génération ajoutant de la flexibilité et des possibilités de simultanéité..

Première génération

Avec les systèmes de contrôle de version d’origine, bien que plusieurs personnes puissent travailler sur le même fichier, elles ne pouvaient pas le faire simultanément. Le fichier a été verrouillé pour empêcher les autres d’y accéder en même temps.

Un exemple d’un tel outil est le SCCS (Source Code Control System) pour le développement de logiciels à partir de 1972. RCS (Revision Control System) a été créé comme l’alternative gratuite au SCCS et offrait un fonctionnement, des branches et des fusions plus rapides (permettant toujours à un seul développeur de travailler sur un fichier à un moment donné).

Deuxième génération

De nombreux contrôles de version en vigueur aujourd’hui appartiennent à cette catégorie. Des modifications simultanées sur les fichiers sont possibles, bien que les utilisateurs doivent fusionner les révisions en cours dans leur travail avant de pouvoir valider.

CVS (Concurrent Versions System) est une instance et permet des interactions client / serveur avec l’utilisation d’un référentiel. SVN (ou Apache Subversion dans son intégralité) est probablement le plus populaire de tous les systèmes de contrôle de version utilisés aujourd’hui.

SVN peut être considéré comme une refonte de CVN avec une fondation moderne et des solutions aux anciennes limitations CVS.

Troisième génération

Également connu sous le nom de DVCS (Distributed Version Control Systems), avec la possibilité de séparer les opérations de fusion et de validation, l’un des exemples les plus connus est Git.

Il n’y a plus de base centralisée pour les fichiers; différentes branches contiennent différentes parties, ce qui ouvre également la porte à des révisions hors ligne.

Un vrai exemple avec Git

A quoi ressemblent les opérations décrites ci-dessus lors de l’utilisation d’un système de contrôle de version réel?

Nous prenons Git comme exemple ici, en utilisant la ligne de commande Linux. Tout d’abord, nous créons un référentiel Git pour le répertoire dans lequel nous nous trouvons actuellement. Nous utilisons la commande pwd pour voir où nous en sommes:

1
2

$ pwd

/ Users / HJ / Desktop / repos / apps

Ensuite, nous utilisons la commande git init pour créer le référentiel (le référentiel «maître») et obtenir une confirmation de Git:

1
2

$ git init

Référentiel Git vide initialisé dans /Users/HJ/Desktop/repos/apps/.git

Supposons que nous ajoutions un nouveau fichier, main.c, à notre répertoire de travail. L’utilisation de la commande git status nous donnera les informations suivantes:

1
2
3
4
5
6
7
8
9

$ git status

# Sur le maître de succursale
#
# Initial commit
#
# Fichiers non suivis:
# (utilisation "git add …" à inclure dans ce qui sera engagé)
#
# principal c

Nous utilisons git add pour suivre le fichier main.c

1 $ git add main.c

Nous utilisons git commit avec un message (option -m) sur ce que nous faisons pour valider les modifications dans le fichier main.c.

1 $ git commit -m "ajout de main.c au référentiel"

Maintenant, nous pouvons créer une branche (par exemple, “test”) avec la commande git branch:

1 $ git branch test

Utiliser à nouveau la commande git branch seule, répertorie simplement les référentiels que nous avons maintenant:

1
2
3

$ git branch

tester

* Maître

Enfin, pour commencer à travailler dans la branche «test» sur la copie de main.c maintenant dans cette branche, nous utilisons la commande git checkout pour obtenir la confirmation que nous travaillons maintenant dans la branche «test».

1
2

$ git checkout test

Passé en succursale "tester"

Pour revenir à la branche «master», utilisez simplement à nouveau la commande git checkout:

1
2

$ git checkout master

Passé en succursale "Maître"

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me