Pourquoi les utilisateurs de Git disent-ils que Subversion n'a pas tout le code source localement?


23

Je ne fais que ce que j'ai lu sur SO, alors pardonnez-moi, mais tout ce que j'ai lu dit que l'un des principaux avantages de Git par rapport à Subversion est que Git donne tout le code source au développeur localement, sans rien avoir à faire sur le serveur.

Avec mon utilisation limitée de SVN et TortoiseSVN, j'avais tout le code source, ou du moins je pensais l'avoir fait. Par exemple, j'ai un site Web. Je le télécharge sur SVN. Je gère toujours mon site Web localement, n'est-ce pas? Si quelqu'un soumet une modification et que je ne suis pas connecté, cela n'aurait pas d'importance si j'avais Git ou non, jusqu'à ce que je me reconnecte au serveur.

Je ne comprends pas. Je ne demande pas une refonte de l'un contre l'autre, sauf ce point.


2
Ce n'est pas que vous ayez tout votre code source localement, c'est que vous avez tout l'historique du référentiel localement. Cela rend toutes les interactions de référentiel autres que la synchronisation du serveur beaucoup plus rapides.
stonemetal

Réponses:


69

La prémisse que vous interrogez est vraiment fausse:

que l'un des principaux avantages de Git par rapport à Subversion est que Git donne tout le code source au développeur localement

Avec Subversion et Git, vous avez votre code source localement. Avec Git, vous disposez à la fois de votre code source et d'un référentiel sur votre machine locale.

Ca fait plutot comme ca.

Subversion:

Votre code <-> Le référentiel

Git:

Votre code <-> Votre référentiel local <-> Un référentiel distant (... <-> un autre référentiel distant, etc.)

Un avantage que vous obtenez de cette structure est que vous pouvez toujours utiliser le contrôle de code source et valider vos modifications locales dans votre référentiel local sans perturber le travail des autres membres de l'équipe (avec qui vous partagez le référentiel distant).

Avec Subversion, vous devriez soit risquer de casser la version pour d'autres personnes, soit subir un développement local prolongé sans aucun contrôle de source, ce qui se termine par un énorme commit (ou plus probablement un retour).

Avec Git, d'autre part, vous vous sentiriez libre de valider ces modifications dans votre référentiel local, d'afficher les journaux et les différences ou vos modifications, et uniquement lorsque vous vous sentez prêt à être partagé avec l'équipe, envoyez les modifications à partir du local référentiel vers le référentiel distant.


10
Ceci est une très bonne réponse et frappe vraiment à la maison avec "... risque de casser la construction pour d'autres personnes ou de subir un développement local prolongé sans aucun contrôle de source ..."
Charles Sprayberry

1
@cspray: Merci! Je suis sûr qu'il y a aussi d'autres avantages, mais c'est la plus grande douleur que j'ai eue avec Svn.
Goran Jovic

git FTW (8 de plus à parcourir ...)
Trevor Boyd Smith

2
@DanNeely: En fait, c'est le cas - OP a posé des questions sur une affirmation qu'il a lue quelque part et la réponse est que ce n'est tout simplement pas vrai (voir la première partie de ma réponse). La deuxième partie est juste une explication de ce que celui qui a fait la réclamation voulait probablement dire et pourquoi.
Goran Jovic

1
@Giorgio: Essayez-le et vous le saurez :) Sérieusement, je ne pense pas avoir réussi à le faire sans problème (à part faire une fusion complètement manuelle, ce qui va à l'encontre du but de l'outil)
Goran Jovic

17

Git ou Mercurial stockent l'intégralité de votre référentiel localement avec toutes les révisions et les branches nommées. Subversion n'en stocke qu'un seul - généralement la révision de tête. Ainsi, avec Git et Mercurial, vous pouvez accéder au référentiel complet (c'est-à-dire votre code source actuel et son historique) même lorsque votre réseau tombe en panne avec SVN, vous êtes limité à la dernière révision que vous avez mise à jour.


1
@Murph Merci. C'était essentiellement ce que je voulais dire. J'ai essayé de clarifier.
Amenti

Ce n'est pas seulement une question de savoir si vous avez une connexion réseau au serveur ou non; les E / S locales sont beaucoup plus rapides et à latence plus faible que les E / S réseau, ce qui rend l'examen de l'historique ou blâmer un fichier beaucoup plus rapide (avertissement de blâme de TrotiseSVN "Veuillez patienter - cela peut prendre plusieurs minutes. Sérieusement!"). Le compromis est qu'avoir tout l'historique local peut nécessiter beaucoup plus d'espace disque dans les grands référentiels; cela peut être problématique sur les ordinateurs portables si vous ne pouvez pas simplement ajouter un lecteur supplémentaire pour compléter un SSD plus petit qui ne fait pas faillite.
Dan Neely

Le commentaire de @ DanNeely était probablement raisonnable en 2012, mais 4 ans plus tard, il est presque impossible de trouver un projet git qui puisse occuper une partie importante d'un SSD
Igor Stoppa

7

La réponse courte est la suivante: avec git vous avez tout votre code source, avec subversion vous avez toute la version la plus récente de votre code source.

Git conserve une copie de l'historique complet de votre référentiel localement. Avec subversion, tout l'historique est sur un serveur.


2

Je pense que ce que vous voulez dire, c'est qu'avec SVN, toutes vos actions nécessitent une communication avec le serveur, contrairement à GIT. Avec SVN, si vous voulez créer une branche, vous branchez sur le serveur et déroulez cette branche. Avec GIT, vous pouvez créer une branche locale sans que le "serveur" en soit informé.

Vous avez raison de dire que vous disposez du code source à la fois avec SVN et GIT, mais avec GIT, il n'est pas nécessaire qu'il y ait un serveur centralisé contenant également le code source. Avec GIT, vous pouvez être la SEULE personne avec le code source, tout en étant capable de faire toutes les fonctions que vous auriez avec un VCS typique.

J'ai entendu des arguments contre GIT, et je pense que cela peut aider votre question, en disant que puisque vous n'êtes pas obligé de vous engager dans un référentiel central, vous êtes propriétaire de votre code source jusqu'à ce que vous l'ayez validé et poussé vers votre serveur, si tu en as un. Avec SVN, la seule façon d'avoir le contrôle de version est de vous engager sur le serveur, mais avec GIT, vous pourriez potentiellement tout garder sur votre machine locale et si tout va mal, vous "pourriez tout perdre" même si vous le pouviez tout aussi facilement perdez toutes vos modifications avec SVN si vous ne vous êtes pas engagé et que votre disque dur s'est également écrasé.


1

en disant que puisque vous n'êtes pas obligé de valider un référentiel central, vous êtes propriétaire de votre code source jusqu'à ce que vous l'ayez validé et poussé vers votre serveur, si vous en avez un. Avec SVN, la seule façon d'avoir le contrôle de version est de vous engager sur le serveur, mais avec GIT, vous pourriez potentiellement tout garder sur votre machine locale et si tout va mal, vous "pourriez tout perdre" même si vous le pouviez tout aussi facilement perdez toutes vos modifications avec SVN si vous ne vous êtes pas engagé et que votre disque dur s'est également écrasé.

Si vous poussez quotidiennement, le risque devrait être faible. Mais si vous êtes obligé de vous engager quotidiennement sur le serveur SVN, à la fin de la journée, vous pouvez tout faire dans un seul grand ensemble de modifications, qui ne sépare pas chaque modification en petites étapes. Avec git, vous êtes encouragé à faire plusieurs petits commits. En poussant, si la fusion est nécessaire, essayez de fusionner et de pousser. Si vous ne pouvez pas fusionner pour le moment, vous pouvez pousser vers une nouvelle branche ou un autre référentiel sur le serveur.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.