Explication détaillée de la différence entre GIT et SVN

GIT n'est pas seulement un système de contrôle de version, c'est aussi un système de gestion de contenu (CMS), un système de gestion du travail, etc. Si vous avez une expérience dans l'utilisation de SVN, vous devez effectuer quelques changements mentaux pour vous adapter à certains des concepts et fonctionnalités fournis par GIT. Par conséquent, l’objectif principal de cet article est de vous aider à le comprendre en présentant ce que GIT peut faire et en quoi il diffère de SVN à un niveau plus profond.

1. GIT est distribué, SVN ne l'est pas :

C'est le cœur de GIT et d'autres systèmes de contrôle de version non distribués, tels que SVN, CVS, etc. . différence. Si vous pouvez comprendre ce concept, vous êtes à mi-chemin. Un petit avertissement doit être fait, GIT n'est pas le premier ni le seul système de contrôle de version distribué actuellement. Certains systèmes, tels que Bitkeeper, Mercurial, etc., fonctionnent également en mode distribué. Mais GIT fait un meilleur travail à cet égard et possède des fonctionnalités plus puissantes.

GIT, comme SVN, possède son propre référentiel ou serveur centralisé. Cependant, GIT préfère être utilisé en mode distribué, c'est-à-dire que chaque développeur clonera son propre référentiel sur sa machine après avoir extrait le code du référentiel/serveur central. On peut dire que si vous êtes coincé dans un endroit sans accès à Internet, comme dans un avion, dans un sous-sol, dans un ascenseur, etc., vous pouvez toujours soumettre des fichiers, consulter les enregistrements de versions historiques, créer des branches de projet, etc. Pour certains, cela peut ne pas sembler très utile, mais lorsque vous vous retrouvez soudainement dans un environnement sans réseau, cela résoudra votre gros problème.

De même, ce mode de fonctionnement distribué est également un énorme cadeau pour le développement de la communauté du logiciel open source. Vous n'avez plus besoin de créer des packages de correctifs et de les envoyer par e-mail comme avant, il vous suffit de créer un A. branche qui envoie une requête push à l’équipe projet. Cela permet de garder votre code à jour et de ne pas le perdre pendant le transport. GitHub.com est un excellent cas.

Certaines rumeurs se sont répandues selon lesquelles les futures versions de Subversion seront également basées sur le modèle distribué. Mais au moins, ce n'est pas encore visible.

2. GIT stocke le contenu par métadonnées, tandis que SVN stocke le contenu par fichier :

Tous les systèmes de contrôle de ressources masquent les métainformations des fichiers dans des dossiers comme .svn, .cvs, etc. Si vous comparez la taille du répertoire .git avec celle de .svn, vous constaterez qu'elles sont très différentes. Étant donné que le répertoire .git est une version clonée du référentiel sur votre machine, il contient tout ce qui se trouve sur le référentiel central, comme les balises, les branches, les enregistrements de version, etc.

3. Les branches GIT sont différentes des branches SVN :

La branche n'est pas spéciale du tout dans SVN, c'est juste un autre répertoire dans le référentiel. Si vous souhaitez savoir si une branche a été fusionnée, vous devez exécuter manuellement une commande telle que svn propget svn:mergeinfo pour confirmer si le code a été fusionné. Merci à son camarade de classe Ben d'avoir signalé cette fonctionnalité. Il arrive donc souvent que certaines branches soient manquées.

Cependant, travailler avec les branches GIT est assez simple et amusant. Vous pouvez rapidement basculer entre plusieurs branches à partir du même répertoire de travail. Vous pouvez facilement trouver des branches non fusionnées et fusionner ces fichiers rapidement et facilement.

4. GIT n'a pas de numéro de version global, alors que SVN en a :

Jusqu'à présent, c'est la plus grande fonctionnalité qui manque à GIT par rapport à SVN. Vous savez également que le numéro de version SVN est en fait un instantané du code source à tout moment correspondant. Je pense que c'est la plus grande avancée dans l'évolution de CVS vers SVN. Parce que GIT et SVN sont conceptuellement différents, je ne sais pas quelles fonctionnalités de GIT leur correspondent. Si vous avez des indices, partagez-les avec tout le monde dans les commentaires.

Mise à jour : certains lecteurs ont souligné que nous pouvons utiliser le SHA-1 de GIT pour identifier de manière unique un instantané de code. Cela ne remplace pas complètement les numéros de version numériques faciles à lire dans SVN. Toutefois, le but devrait être le même.

5. L'intégrité du contenu de GIT est meilleure que celle de SVN :

Le stockage de contenu de GIT utilise l'algorithme de hachage SHA-1. Cela garantit l'intégrité du contenu du code et réduit les perturbations du référentiel en cas de panne de disque et de problèmes de réseau. Il y a une bonne discussion sur l'intégrité du contenu GIT ici - http://stackoverflow.com/questions/964331/git-file-integrity

Est-ce les cinq seules différences entre GIT et SVN ? Bien sûr que non. Je suppose que ces 5 ne sont que les « plus basiques » et « les plus attrayants ».

Introduction à la différence entre git et svn

Pourquoi le contrôle de version est nécessaire

Git et svn sont tous deux utilisés par les programmeurs pour gérer le code, si Lorsqu’une seule personne développe un projet, le contrôle de version ne sert à rien, n’est-ce pas ? Cependant, lors du développement dans une entreprise, il est presque impossible qu'une seule personne soit responsable d'un projet : de l'examen des exigences à la conception de l'interface utilisateur, en passant par le développement front-end, le développement back-end et les tests, l'ensemble du processus nécessite la coopération d'un. équipe. À l’heure actuelle, le contrôle de version est particulièrement important.

Différence

Parlons de la différence entre git et svn :

SVN est un système de contrôle de version centralisé et git est un système de contrôle de version distribué.
Je crois que beaucoup de gens ont entendu cette phrase. Qu'est-ce qui est centralisé et distribué ? Évidemment, littéralement, dans svn, tout le monde modifie le programme sur le serveur. Si quelqu'un modifie la même partie, il y aura un conflit. Par conséquent, l'équipe générale conviendra que pour la partie publique du programme, essayez de marquer l'identification unique du développeur, ou ajoutez A en haut et B en bas.
Git signifie que les développeurs créent leurs propres branches. Cette branche équivaut à copier le code source sur la machine locale. Après cela, tout le code local peut être extrait à tout moment pour la synchronisation que Git peut créer. d'innombrables Pour les branches, les développeurs n'ont qu'à soumettre leur code modifié, le risque de conflits sera donc beaucoup plus faible.
SVN interagit directement avec le serveur, tandis que git met le projet en cache localement puis le transmet au serveur.
SVN doit fonctionner lorsqu'il est connecté à Internet, mais git peut être développé sans connexion Internet.
SVN est sujet aux conflits, mais git n'est pas sujet aux conflits.
SVN est conçu pour la gestion de projet et git est conçu pour la gestion de code.
SVN convient au développement parallèle de plusieurs projets, et git convient au développement d'un seul projet.
SVN convient à un usage interne au sein d'une entreprise, le chef de projet coordonnant le développement global de plusieurs projets. Git convient à plusieurs personnes développant le même projet via le réseau.

git et github

Créer une phrase pour refléter la relation entre les deux
mio a utilisé git pour soumettre le projet à github
C'est-à-dire : git est un outil et github est une plateforme.

Enfin

Je ne sais pas qui j'ai entendu auparavant, mais le sens d'écrire un blog technique n'est pas de se souvenir, mais d'enseigner. Cette phrase a vraiment du sens. Bien que les mots que j'écris maintenant ne soient pas du tout professionnels et ressemblent à un amateur, je ferai de mon mieux

Ce qui suit est l'ajout de Baipao Jun

Seulement quand on est compris et pensé en place, peut-il être ciblé une fois implémenté. Les autres ne peuvent être réalisés que lorsqu'ils sont utilisés

1) La différence fondamentale est que Git est distribué, alors que Svn ne l'est pas. Si vous comprenez cela, il sera facile de commencer. Permettez-moi de préciser que Git n'est pas le seul système de contrôle de version distribué actuellement. Il existe également Mercurial, etc., donc ils sont à peu près les mêmes. Cela dit, comme Svn, Git possède son propre référentiel et son propre serveur centralisé, mais Git est plus enclin au développement distribué, car chaque développeur dispose d'un référentiel local sur son ordinateur, ce qui lui permet de s'engager même s'il n'y a pas de réseau. Voir la version historique. enregistrements, création de branches de projet et autres opérations, attendez que le réseau soit à nouveau connecté et envoyez-le au serveur.

D'après ce qui précède, Git a l'air vraiment génial, mais Git ajoute de la complexité, ce qui peut être un peu déroutant au début, car vous devez créer deux référentiels (dépôts locaux et référentiels distants), et il existe de nombreux instructions. De plus, vous devez savoir quelles instructions se trouvent dans le référentiel local et quelles instructions se trouvent dans le référentiel distant.

2) Git stocke le contenu sous forme de métadonnées, tandis que SVN stocke le contenu sous forme de fichiers : parce que le répertoire .git est une version clonée du référentiel sur votre machine et qu'il contient tout le contenu du référentiel central. balises, branches, enregistrements de version, etc. En comparant la taille du répertoire .git avec celle de .svn, vous constaterez qu’elles sont très différentes.

3) Git n'a pas de numéro de version global, mais SVN en a : jusqu'à présent, c'est la plus grande fonctionnalité qui manque à Git par rapport à SVN.

4) L'intégrité du contenu de Git est meilleure que celle de SVN : le stockage de contenu de GIT utilise l'algorithme de hachage SHA-1. Cela garantit l'intégrité du contenu du code et réduit les perturbations du référentiel en cas de panne de disque et de problèmes de réseau.

5) Après avoir téléchargé Git, vous pouvez voir tous les journaux en état hors ligne, mais pas SVN.

6) C'est très ennuyeux au début. SVN doit être mis à jour avant de s'engager. Si vous oubliez de fusionner, certaines erreurs se produiront. Cette situation est relativement rare dans git.

7) Cloner un tout nouveau répertoire Par exemple, s'il comporte également cinq branches, SVN copie 5 versions de fichiers en même temps, ce qui signifie répéter la même action cinq fois. Git récupère simplement les éléments de chaque version du fichier, puis charge uniquement la branche principale (master). D'après mon expérience, un clone a près de 10 000 commits (commits), cinq branches, chaque branche en a environ 1 500. Le fichier SVN a pris près de 1 500 commits (commits). une heure ! Et Git n’a pris qu’une minute !

8) Dépôt : SVN ne peut avoir qu'un seul référentiel central désigné. Lorsqu'il y a un problème avec ce référentiel central, tous les membres actifs sont paralysés jusqu'à ce que le référentiel soit réparé ou qu'un nouveau référentiel soit créé. Git peut avoir un nombre illimité de référentiels. Ou, pour être plus correct, chaque Git est un référentiel, la différence est de savoir s'ils ont un répertoire actif (Git Working Tree). Si quelque chose arrive au référentiel principal (par exemple : le référentiel placé sur GitHub), les membres actifs peuvent toujours s'engager dans leur référentiel local et attendre que le référentiel principal soit restauré. Les membres actifs peuvent également s'engager dans d'autres référentiels !

9) Branche Dans SVN, une branche est un répertoire complet. Et ce répertoire contient des fichiers réels complets. Si un membre du personnel voulait créer une nouvelle succursale, cela aurait un impact « sur le monde entier » ! Tout le monde aura la même branche que vous. Si votre branche est utilisée pour des travaux de sabotage (tests de sécurité), ce sera comme une maladie infectieuse. Si vous changez de branche, d'autres devront recouper la branche et la télécharger à nouveau, ce qui est très sanglant. Avec Git, chaque membre actif peut ouvrir un nombre illimité de branches dans son propre référentiel local. Par exemple : lorsque je veux essayer de casser mon propre programme (test de sécurité) et que je souhaite conserver ces fichiers modifiés pour une utilisation ultérieure, je peux ouvrir une branche et faire ce que je veux. Pas besoin de craindre de gêner les autres membres du personnel. Tant que je ne fusionne pas et ne m'engage pas dans le référentiel principal, personne au travail ne sera affecté. Lorsque je n'ai plus besoin de cette branche, je la supprime simplement de mon référentiel local. Indolore et démangeant.

Les noms de branches Git peuvent utiliser des noms différents. Par exemple : ma branche locale s'appelle OK, mais le nom dans le référentiel principal est en fait master.

La chose la plus remarquable est que je peux ouvrir une branche à n'importe quel point de commit dans Git ! (Une méthode consiste à utiliser gitk –all pour observer l'intégralité de l'enregistrement de soumission, puis à ouvrir la branche à tout moment.)

10) Soumettre (Commit) Dans SVN, lorsque vous soumettez votre produit fini, il sera être directement enregistré dans le référentiel central. Lorsque vous découvrez quelque chose de grave dans votre produit fini, vous ne pouvez rien faire pour l'empêcher de se produire. Si le réseau est en panne, vous ne pouvez pas soumettre du tout ! Les soumissions Git sont entièrement des activités dans le référentiel local. Et vous venez de "git push" vers le référentiel principal. Le "push" de Git effectue en fait une "synchronisation" (Sync).

Enfin, pour résumer :

SVN se caractérise par sa simplicité, et il est acceptable de l'utiliser lorsque vous avez juste besoin d'un endroit pour mettre du code.

Le contrôle de version des fonctionnalités de Git peut tout faire sans dépendre du réseau, et offre un meilleur support pour les branchements et les fusions (bien sûr, c'est ce qui préoccupe le plus les développeurs), mais je veux que vous l'utilisiez mieux, vous besoin Prenez le temps de l'essayer.

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!