À quel système de contrôle de version appartient git ?

Git est un système de contrôle de version distribué. Git est un logiciel de contrôle de version distribué open source développé par Linus Torvalds pour aider à gérer le développement du noyau Linux. Il est utilisé pour gérer efficacement et rapidement la gestion des versions de projets, des petits aux très grands projets.

L'environnement d'exploitation de ce tutoriel : système Windows 7, mysql version 8.0.22, ordinateur Dell G3.

À quel système de contrôle de version appartient git ?

Git est un système de contrôle de version distribué.

Git a les caractéristiques suivantes :

• Le référentiel de chaque clone dans Git est égal. Vous pouvez créer votre propre référentiel à partir d'un clone de n'importe quel référentiel, et votre référentiel peut également être utilisé comme source pour d'autres si vous le souhaitez.

• Chaque opération d'extraction de Git est en fait une sauvegarde complète du référentiel de code.

• La soumission est entièrement effectuée localement, personne d'autre n'a besoin de vous donner d'autorisation, vous êtes le maître de votre référentiel et la soumission sera toujours réussie.

• Même les modifications basées sur l'ancienne version peuvent être soumises avec succès, et la soumission créera une nouvelle branche basée sur l'ancienne version.

• Les soumissions Git ne seront pas interrompues jusqu'à ce que vous soyez entièrement satisfait de votre travail. PUSH vers d'autres ou d'autres pour PULL votre référentiel se produira pendant les processus PULL et PUSH vous demandera terminé. manuellement.

• La résolution des conflits n'est plus comme un concours de soumission comme SVN, mais une fusion et une résolution des conflits uniquement en cas de besoin.

• Git peut également simuler un mode de travail centralisé

• Le dépôt Git est placé sur le serveur

• Vous pouvez autoriser le dépôt Git : qui peut créer le dépôt, qui peut pousser vers le dépôt, qui peut lire (cloner) le référentiel ?

• Les membres de l'équipe clonent d'abord le référentiel du serveur localement ; et extraient fréquemment (PULL) les dernières mises à jour du référentiel du serveur

• Les membres de l'équipe pousseront (PUSH) vos propres modifications vers le référentiel du serveur ; référentiel, et lorsque d'autres se synchroniseront avec le référentiel (PULL), ils obtiendront automatiquement les modifications

• Le mode de travail centralisé de Git est très flexible

• Vous pouvez complètement Lorsque vous êtes loin du réseau où se trouve le serveur Git , par exemple lorsque vous travaillez en déplacement/en voyage d'affaires, vous pouvez toujours utiliser la bibliothèque de codes comme d'habitude

• Il vous suffit d'utiliser PULL et PUSH pour terminer la synchronisation avec le serveur et indiquer quand vous pouvez accéder au réseau où le serveur Git est situé

• Git fournit la commande rebase, qui peut donner l'impression que vos modifications sont basées sur les dernières modifications de code

• Git propose plus de modes de fonctionnement, bien plus que ce que Subversion peut égaler

Qu'est-ce que le "contrôle de version" ?

Le contrôle de version est un système qui enregistre les modifications dans le contenu d'un ou plusieurs fichiers afin que vous puissiez vérifier l'état de révision d'une version spécifique et revenir en arrière dans le futur. Tout type de fichier peut être contrôlé en version.

Si vous êtes un graphiste ou un concepteur Web, vous devrez peut-être enregistrer toutes les révisions d'un certain fichier d'image ou de mise en page (cela peut être une fonctionnalité que vous désirez vraiment avoir). Il est sage d'utiliser un système de contrôle de version (). VCS) choisissez.

Avec lui, vous pouvez restaurer un fichier à son état précédent, ou même restaurer l'ensemble du projet à son état à un moment donné dans le passé. Vous pouvez comparer les détails des modifications des fichiers et découvrir qui a modifié lequel dans le passé. le point final pour découvrir ce qui a causé des problèmes étranges, qui a signalé un bug de fonctionnalité, à quel moment, et plus encore.

L'utilisation d'un système de contrôle de version signifie généralement également que même si vous gâchez et supprimez des fichiers dans l'ensemble du projet, vous pouvez toujours facilement les restaurer à leur état d'origine. Mais la charge de travail supplémentaire est minime.

Système de contrôle de version local

De nombreuses personnes sont habituées à copier l'intégralité du répertoire du projet pour enregistrer différentes versions, et peuvent également changer le nom et ajouter l'heure de sauvegarde pour montrer la différence. Le seul avantage de cette méthode est que c’est simple, mais il est également très facile de faire des erreurs. Parfois, le répertoire de travail est confus et le mauvais fichier est accidentellement écrit ou un fichier inattendu est écrasé.

Afin de résoudre ce problème, les gens ont développé il y a longtemps de nombreux systèmes de contrôle de version locaux, dont la plupart utilisent une sorte de base de données simple pour enregistrer les différences dans les mises à jour précédentes des fichiers.

Figure 1. Contrôle de version local.

Le plus populaire s'appelle RCS, et on peut encore le voir sur de nombreux systèmes informatiques aujourd'hui. La commande rcs peut être utilisée même après l'installation du kit d'outils de développement sur les systèmes Mac OS X populaires. Cela fonctionne en enregistrant un ensemble de correctifs (un correctif est une modification avant et après la révision d'un fichier) sur le disque dur ; en appliquant tous les correctifs, le contenu de chaque version du fichier peut être recalculé.

Système de contrôle de version centralisé

Ensuite, les gens rencontrent un autre problème, comment permettre aux développeurs de différents systèmes de travailler ensemble ?

Par conséquent, des systèmes de contrôle de version centralisés (systèmes de contrôle de version centralisés, CVCS en abrégé) ont vu le jour. De tels systèmes, tels que CVS, Subversion et Perforce, disposent d'un seul serveur géré de manière centralisée qui enregistre les révisions de tous les fichiers, et les personnes travaillant ensemble se connectent à ce serveur via des clients pour récupérer les derniers fichiers ou renouveler leur validation. Cela est devenu une pratique courante pour les systèmes de contrôle de version au fil des années.

Figure 2. Contrôle de version centralisé.

Cette approche apporte de nombreux avantages, notamment par rapport au VCS local à l'ancienne. Désormais, chacun peut voir dans une certaine mesure sur quoi travaillent les autres participants au projet. Les administrateurs peuvent également contrôler facilement les autorisations de chaque développeur, et gérer un CVCS est bien plus simple que maintenir des bases de données locales sur chaque client.

Il y a deux côtés aux choses, le bon et le mauvais. L’inconvénient le plus évident de cette méthode est que le serveur central constitue un point de défaillance unique. S'il est indisponible pendant une heure, personne ne peut soumettre de mises à jour pendant cette heure et personne ne peut travailler ensemble. Si le disque sur lequel réside la base de données centrale est corrompu et que vous ne le sauvegardez pas correctement, vous perdrez sans aucun doute toutes les données, y compris l'historique complet des modifications du projet, ne laissant que les instantanés individuels que les utilisateurs conservent sur leurs propres machines. Un problème similaire existe avec les systèmes de contrôle de version locaux. Tant que l'historique complet du projet est conservé au même endroit, il existe un risque de perdre tous les enregistrements de mises à jour historiques.

Système de contrôle de version distribué

Ainsi, le système de contrôle de version distribué (DVCS) est né. Dans de tels systèmes, tels que Git, Mercurial, Bazaar et Darcs, le client extrait non seulement la dernière version de l'instantané de fichier, mais reflète également complètement le référentiel de code. De cette manière, si un serveur utilisé pour le travail collaboratif tombe en panne, n'importe quel entrepôt local en miroir peut être utilisé pour effectuer une récupération ultérieure. Parce que chaque opération de clonage est en réalité une sauvegarde complète du référentiel de code.

Figure 3. Contrôle de version distribué

De plus, bon nombre de ces systèmes peuvent être spécifiés pour interagir avec plusieurs référentiels de codes distants différents. De cette façon, vous pouvez collaborer avec des personnes de différents groupes de travail sur le même projet. Vous pouvez configurer différents processus de collaboration selon vos besoins, tels que des flux de travail basés sur des modèles hiérarchiques, ce qui n'était pas possible dans les systèmes centralisés précédents.

Apprentissage recommandé : "Tutoriel Git"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!