Systèmes de contrôle de version

« Salut Amigo ! »

"Salut!"

"Aujourd'hui, je vais vous parler des systèmes de contrôle de version."

"Comme vous le savez probablement déjà, les programmes sont souvent très volumineux et prennent beaucoup de temps à écrire. Parfois, des dizaines de personnes peuvent passer des années à écrire un programme."

"Les projets avec des millions de lignes de code sont une réalité."

"Waouh."

"C'est très compliqué. Les gens interfèrent souvent les uns avec les autres, et modifient souvent le même code, et ainsi de suite."

"Pour mettre de l'ordre dans ce gâchis, les programmeurs ont commencé à utiliser des systèmes de contrôle de version pour leur code."

" Un système de contrôle de version est un programme composé d'un client et d'un serveur.

"Le programme stocke les données (le code écrit par les programmeurs) sur un serveur, et les programmeurs les ajoutent ou les modifient à l'aide de clients."

"La principale différence entre un système de contrôle de version et des programmes qui permettent simplement de travailler en collaboration sur des documents est qu'il stocke toutes les versions précédentes de tous les documents (fichiers de code)."

"Peux-tu me donner plus de détails. Comment ça marche ?"

"Imaginez que vous êtes un programmeur et que vous souhaitez apporter de petites modifications au code source d'un programme stocké dans un référentiel sur le serveur."

"Voici ce que vous devez faire :"

"1) Connectez-vous au serveur."

"2) Copiez la dernière version de tous les fichiers sur votre ordinateur à l'aide de la commande Checkout."

"3) Apportez des modifications aux fichiers requis."

"4) Exécutez le programme localement pour vous assurer qu'il se compile et s'exécute."

"5) Envoyez vos "modifications" au serveur à l'aide de la commande Commit."

"Cela a généralement du sens."

"Mais il y a plus. Imaginez que vous arrivez au travail le matin, mais qu'il est déjà l'heure du déjeuner en Inde. Vos collègues indiens ont donc déjà apporté des modifications et validé leurs modifications dans votre référentiel sur le serveur."

"Vous devez travailler avec la dernière version du code. Vous exécutez donc la commande Mettre à jour ."

"En quoi est-ce différent de Checkout ?"

" Checkout est conçu pour copier tous les fichiers du référentiel, mais Update ne met à jour que les fichiers qui ont été mis à jour sur le serveur depuis la dernière exécution d'une commande Checkout / Update ."

"C'est à peu près comme ça que ça marche :"

Caisse :

"Maintenant, disons que nous avons modifié le fichier B et que nous voulons le télécharger sur le serveur. Pour ce faire, nous devons utiliser la commande Commit ."

"Et voici comment fonctionne la commande Update :"

« Comme c'est intéressant ! Y a-t-il d'autres commandes ?

"Oui, il y en a plusieurs. Mais ils varient en fonction du programme de contrôle de version que vous choisissez. J'essaie donc d'expliquer simplement les principes généraux."

"Il existe également une opération appelée fusion - l'union de deux documents. Supposons que deux programmeurs modifient le même fichier en même temps. Ensuite, le programme sur le serveur ne permettra pas que les deux modifications soient validées. Celui qui commet le premier peut ajouter son ou ses changements."

"Alors que fait l'autre personne ?"

"Il ou elle sera invité à effectuer une opération de mise à jour pour récupérer les dernières modifications du serveur. Au fait, cela - faire une mise à jour avant de s'engager - est une bonne pratique."

"Ensuite, lors de l'opération de mise à jour, le programme client tentera de fusionner les modifications locales avec les modifications reçues du serveur."

"Si les programmeurs ont modifié différentes parties du fichier, le programme de contrôle de version sera probablement en mesure de les fusionner avec succès.  Si les modifications se trouvent au même endroit, le programme de contrôle de version signalera un conflit de fusion et invitera l'utilisateur à le faire manuellement. fusionner les modifications."

"Par exemple, cela se produit souvent lorsque les deux programmeurs ajoutent quelque chose à la fin d'un fichier."

"Je vois. Dans l'ensemble, cela semble raisonnable."

« Et il y a encore une chose : des branches.

"Imaginez que deux programmeurs d'une équipe soient chargés de réécrire le même module. Ou mieux encore, de le réécrire à partir de zéro. Tant que ce module n'est pas terminé, le programme ne pourra pas s'exécuter et pourrait même ne pas se compiler."

« Alors, qu'est-ce qu'ils sont censés faire ?

"Ils avancent en ajoutant des branches au référentiel. En gros, cela signifie que le référentiel est divisé en deux parties. Pas par fichiers ou répertoires, mais par versions."

"Imaginez que l'électricité n'ait jamais été découverte et que les robots n'aient jamais été inventés. Alors les trois guerres de libération n'auraient jamais eu lieu, et toute l'histoire humaine aurait suivi un chemin complètement différent. "

"Ce chemin est une branche alternative de l'histoire."

"Ou vous pouvez simplement essayer d'imaginer une branche comme une simple copie du référentiel. En d'autres termes, à un moment donné, nous avons créé un clone du référentiel sur le serveur, de sorte qu'en plus du référentiel principal (souvent appelé le tronc ), nous avons une autre succursale ."

"Eh bien, cela semble plus compréhensible.

« Pourquoi ne pouvez-vous pas simplement dire que nous avons copié le référentiel ? »

"Ce n'est pas une simple copie."

"Ces branches peuvent non seulement être séparées du tronc, mais aussi fusionnées avec lui."

"En d'autres termes, certains travaux peuvent être effectués dans une branche, puis une fois terminés, vous pouvez ajouter la branche du référentiel au tronc du référentiel ?"

"Ouais."

« Et qu'adviendra-t-il des fichiers ?

"Les fichiers seront fusionnés."

"Eh bien, ça a l'air cool. J'espère que c'est aussi cool en action."

"Et puis certains. D'accord, faisons une pause."

"Il y a un tas d'informations utiles  ici "