Différences : 1. SVN est un système de contrôle de version centralisé, tandis que Git est un système de contrôle de version distribué ; 2. SVN est stocké sous forme de fichiers originaux, de plus grande taille, tandis que Git est stocké sous forme de métadonnées. , qui est de très grande taille Small ; 3. Les opérations de branche de Git n'affecteront pas les autres développeurs, mais SVN le fera.
L'environnement d'exploitation de ce tutoriel : système Windows 7, Git version 2.30.0, ordinateur Dell G3.
SVN est l'abréviation de Subversion. Il s'agit d'un système de contrôle de version open source qui prend en charge la plupart des systèmes d'exploitation courants. En tant que système de contrôle de version open source, Subversion gère les données qui changent au fil du temps. Ces données sont placées dans un référentiel central. Cette archive ressemble beaucoup à un serveur de fichiers classique, mais elle mémorise chaque modification de fichier. De cette façon, vous pouvez restaurer le fichier vers une ancienne version ou parcourir l'historique des modifications du fichier. Subversion est un système à usage général qui peut être utilisé pour gérer tout type de fichier, y compris le code source d'un programme.
Le flux de travail de la gestion centralisée est le suivant :
Le cœur de la gestion centralisée du code est le serveur. Tous les développeurs doivent obtenir le code du serveur avant de commencer une nouvelle journée de travail, puis développer, Enfin, résolvez le conflit et soumettez-vous. Toutes les informations de version sont placées sur le serveur. Si vous êtes déconnecté du serveur, on peut dire en gros que les développeurs ne peuvent pas travailler. Voici un exemple :
Commencez une nouvelle journée de travail :
Téléchargez le dernier code de l'équipe projet depuis le serveur.
Entrez dans votre propre branche, travaillez dessus et soumettez le code à votre propre branche sur le serveur toutes les heures (beaucoup de gens ont cette habitude. Parce que parfois vous changez le code encore et encore, et finalement vous voulez le restaurer sur le serveur. précédente) Version horaire, ou voir quel code vous avez modifié au cours de l'heure précédente, vous devez le faire).
L'heure de repos arrive bientôt. Fusionnez votre branche avec la branche principale du serveur. Le travail de la journée est terminé et reflété sur le serveur.
Cette approche apporte de nombreux avantages, notamment par rapport à l'ancien VCS local. 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.
Il y a deux côtés à toute chose, 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 pourra soumettre de mises à jour, de restaurations, de comparaisons, etc. pendant cette heure, et il sera impossible de travailler ensemble. Si le disque du serveur central tombe en panne et qu'aucune sauvegarde n'est effectuée ou que la sauvegarde n'est pas effectuée à temps, il existe un risque de perte de données. Le pire des cas est de perdre complètement tous les enregistrements de modifications historiques de l'ensemble du projet, à l'exception de certaines données instantanées extraites par le client, mais cela reste un problème car vous ne pouvez pas garantir que toutes les données ont été extraites.
En principe, Subversion ne se soucie que des différences spécifiques dans le contenu des fichiers. À chaque fois, il est enregistré quels fichiers ont été mis à jour, ainsi que quelles lignes et contenus ont été mis à jour.
Chaque référentiel a une URL unique (adresse officielle), et chaque utilisateur obtient le code et les données de cette adresse ;
obtient les mises à jour du code et ne peut se connecter qu'à ce référentiel d'adresses unique, se synchroniser avec obtenir les dernières données ;
la soumission doit avoir une connexion réseau (référentiel non local) ;
la soumission nécessite une autorisation, s'il n'y a pas d'autorisation d'écriture, la soumission échouera
la soumission n'est pas possible ; réussir à chaque fois. Si quelqu'un d'autre soumet avant vous, le message "Les modifications sont basées sur des versions obsolètes, mettez d'abord à jour puis soumettez"... et ainsi de suite.
La résolution des conflits est une compétition de vitesse de soumission : ceux qui sont rapides, soumettent ; d'abord, et tout ira bien ; ceux qui sont lents le soumettront en premier, ceux qui, après s'être engagés, risquent d'avoir des problèmes avec la résolution du conflit.
Git est un système de contrôle de version distribué gratuit et open source pour un traitement agile et efficace de tout projet petit ou grand
Git est un système de contrôle de version distribué open source Système de contrôle de version pour gestion de versions efficace et rapide de projets du petit au très grand. Git est un logiciel de contrôle de version open source développé par Linus Torvalds pour aider à gérer le développement du noyau Linux.
La plus grande différence entre distribué et centralisé est que les développeurs peuvent soumettre localement et chaque développeur copie un référentiel Git complet sur la machine locale via git clone
L'image ci-dessous est le processus de développement git classique.
Du point de vue d'un développeur général, git a les fonctions suivantes :
Du point de vue du développeur principal (en supposant que le développeur principal n'a pas besoin de développer du code), git a les fonctions suivantes :
Vérifiez les e-mails ou vérifiez l'état de soumission des développeurs généraux via d'autres méthodes.
Appliquez des correctifs et résolvez les conflits (vous pouvez les résoudre vous-même, ou vous pouvez demander aux développeurs de les résoudre avant de les soumettre à nouveau. S'il s'agit d'un projet open source, vous devez également décider quels correctifs sont utiles et lesquels ne le sont pas).
Soumettez les résultats à un serveur public, puis informez tous les développeurs.
Depuis sa naissance en 2005, Git est devenu de plus en plus mature et parfait. Tout en étant très simple à utiliser, il conserve toujours les objectifs fixés au départ. Il est rapide et extrêmement adapté à la gestion de grands projets. Il dispose également d'un incroyable système de gestion de succursales non linéaire qui peut répondre à divers besoins de développement de projets complexes.
Contrairement à SVN, Git enregistre l'historique des versions et se soucie uniquement de savoir si les données globales du fichier ont changé. Git n'enregistre pas les données différentielles sur les modifications du contenu du fichier. En fait, Git revient plutôt à prendre un instantané des fichiers modifiés et à les enregistrer dans un système de fichiers miniature. Chaque fois qu'une mise à jour est soumise, il analyse les informations d'empreinte digitale de tous les fichiers, prend un instantané du fichier, puis enregistre un index pointant vers l'instantané. Pour améliorer les performances, si le fichier n'a pas changé, Git ne l'enregistrera pas à nouveau, mais établira uniquement une connexion avec le dernier instantané enregistré.
SVN est un système de contrôle de version centralisé. Il existe une métaphore inexacte : SVN = contrôle de version + serveur de sauvegarde SVN ressemble un peu à un entrepôt d'archives lorsqu'il est utilisé et prend en charge la lecture parallèle en écriture. les fichiers et prennent en charge la gestion des versions du code. Les fonctions incluent la récupération, l'importation, la mise à jour, la branche, le renommage, la restauration, la fusion, etc.
Git est un système de contrôle de version distribué. Les commandes d'opération incluent : clone, pull, push, branch, merge, push, rebase. Git est bon pour la gestion des versions du code du programme.
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 où vous ne pouvez pas vous connecter à 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.
Et Git le stocke sous forme de métadonnées, ce qui est très petit ; SVN le stocke sous forme de fichiers originaux, ce qui est relativement volumineux.
GIT stocke le contenu sous forme de métadonnées, tandis que SVN stocke le contenu sous forme de fichiers. Tous les systèmes de contrôle de ressources cachent les métainformations des fichiers dans un dossier similaire à .svn, .cvs, etc.
Si vous comparez la taille du répertoire .git avec celle du .svn, vous constaterez qu'il y a une grande différence entre eux. É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.
La branche n'a rien de spécial 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é.
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.
GIT n'a pas de numéro de version global, contrairement à SVN. C'est de loin 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.
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.
Impact des opérations de branche
Les opérations de branche de Git n'affecteront pas les autres développeurs ; mais SVN le fera lorsque vous créerez une nouvelle branche, tout le monde aura la même branche que vous.
SVN a un bon support chinois, un fonctionnement simple et aucune difficulté d'utilisation. Les artistes, le personnel produit, les testeurs et le personnel de mise en œuvre peuvent facilement démarrer. . L'interface utilisateur est unifiée, les fonctions sont complètes et l'opération est pratique.
Gestion différenciée des versions du code source du programme, la base de code prend très peu de place. Gestion du code facile à brancher. Il ne prend pas en charge le chinois, a une mauvaise prise en charge de l'interface graphique et est difficile à utiliser. Pas facile à promouvoir.
Les objets applicables sont différents. Git convient aux développeurs impliqués dans des projets open source. En raison de leur haut niveau d’expertise, ils se soucient davantage de l’efficacité que de la facilité d’utilisation. SVN est différent, il convient aux équipes de développement d'entreprise ordinaires. C'est plus facile à utiliser.
Les occasions d'utilisation sont différentes. Git convient au développement d'un seul projet avec plusieurs rôles de développement via Internet, et SVN convient au développement de plusieurs projets parallèles au sein de l'entreprise coordonnés par des chefs de projet.
Les stratégies de gestion des autorisations sont différentes. Git n'a pas de contrôle strict de gestion des autorisations. Tant que vous disposez d'un compte, vous pouvez exporter, importer du code et même effectuer des opérations de restauration. SVN a une gestion stricte des autorisations et peut contrôler les autorisations pour un certain sous-répertoire par groupe ou individu. Faites la distinction entre les autorisations de lecture et d’écriture. Plus strictement, les opérations de restauration ne sont pas prises en charge. Assurez-vous que le code est toujours traçable.
Le champ d'utilisation des branches est différent. Dans Git, vous ne pouvez créer une branche que sur l'intégralité de l'entrepôt, et une fois supprimé, il ne peut pas être restauré. Dans SVN, la branche peut cibler n'importe quel sous-répertoire, ce qui est essentiellement une opération de copie. Par conséquent, vous pouvez créer de nombreuses branches hiérarchiques, les supprimer lorsqu'elles ne sont pas nécessaires et simplement consulter l'ancienne version de SVN lorsque vous en aurez besoin à l'avenir.
Sur la base du troisième point, Git convient aux projets logiciels purs, généralement certains projets open source, comme le noyau Linux, busybox, etc. Au contraire, SVN est bon en gestion multi-projets. Par exemple, vous pouvez stocker le script bsp/document de conception/système de fichiers/application/compilation automatisée d'un projet de téléphonie mobile dans un entrepôt SVN, ou stocker les systèmes de fichiers de cinq projets de téléphonie mobile dans un SVN. Les référentiels n (nombre de projets)*m (nombre de composants) doivent être établis dans git. Dans SVN, seuls jusqu'à n ou m sont nécessaires.
Git utilise un identifiant de 128 bits comme numéro de version, et vous devez indiquer de quelle branche il s'agit lors de la vérification, tandis que SVN utilise un numéro de série incrémentiel comme numéro de version unique au monde, ce qui est plus concis et plus simple. comprendre. Bien que vous puissiez utiliser gittag pour créer des alias littéraux, après tout, cela ne concerne que les versions spéciales.
Traçabilité, le processus de développement typique de git est le suivant : établir une branche, développer, soumettre au maître local et supprimer la branche. La conséquence est que les détails des modifications précédentes seront perdus. Et faites la même chose sous SVN sans perdre aucun détail. Voici un lien intéressant qui montre la méthode de travail typique sous git : (avec master comme noyau, créant constamment de nouvelles branches et supprimant les anciennes)
Mise à jour partielle, restauration partielle. Étant donné que SVN crée un dossier .svn dans chaque dossier à des fins de gestion, il peut facilement implémenter des mises à jour ou des restaurations partielles. Si vous souhaitez uniquement mettre à jour certaines parties, svn peut très bien le faire. Dans le même temps, si le code est mal écrit, une restauration partielle peut être facilement réalisée. Bien sûr, git peut également être restauré via des versions historiques, mais une restauration partielle n'est pas facile à réaliser.
Tout d'abord, je suis chef de projet d'une équipe R&D. J'ai utilisé à la fois SVN et Git. SVN est plus adapté à la gestion de projet, et Git ne convient qu'à la gestion de code.
Les membres d'une équipe de R&D comprennent normalement : l'analyse des exigences, la conception, les artistes, les programmeurs, les tests, la mise en œuvre, l'exploitation et la maintenance. Chaque membre a des résultats dans son travail, y compris des documents, du code de conception et du code de programme. gérés de manière centralisée par projet. SVN peut clairement classer et gérer par répertoire, gardant ainsi la gestion de l'équipe de projet dans un état ordonné et efficace.
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!