Devrais-je utiliser SVN ou Git?
Je commence un nouveau projet distribué. Devrais-je utiliser SVN ou Git et pourquoi?
SVN est un référentiel et de nombreux clients. Git est un dépôt avec beaucoup de pensions client, chacune avec un utilisateur. Il est décentralisé à un point où les utilisateurs peuvent suivre leurs propres modifications localement sans avoir à transférer des éléments sur un serveur externe.
SVN est conçu pour être plus central, où Git est basé sur le fait que chaque utilisateur possède son propre référentiel Git et que celui-ci reporte les modifications dans un référentiel central. Pour cette raison, Git donne aux utilisateurs un meilleur contrôle de version local.
En attendant, vous avez le choix entre TortoiseGit , GitExtensions (et si vous hébergez votre référentiel git "central" sur github, leur propre client - GitHub pour Windows ).
Si vous cherchez à sortir de SVN, vous voudrez peut-être évaluer Bazaar un peu. Il fait partie de la prochaine génération de systèmes de contrôle de version dotés de cet élément distribué. Il n'est pas dépendant de POSIX comme git donc il existe des versions natives de Windows et il est soutenu par de puissantes marques open source.
Mais vous n’avez peut-être même pas encore besoin de ces fonctionnalités. Examinez les caractéristiques, avantages et inconvénients des VCS distribués . Si vous avez besoin de plus que des offres SVN, envisagez-en une. Si vous ne le faites pas, vous voudrez peut-être vous en tenir à l'intégration de bureau supérieure (actuellement) de SVN.
Je n'ai jamais compris ce concept de "git ne soit pas bon sous Windows"; Je développe exclusivement sous Windows et je n’ai jamais eu de problèmes avec git.
Je recommanderais certainement git plutôt que Subversion; il est tout simplement beaucoup plus polyvalent et permet le "développement hors ligne" d’une manière que Subversion n’a jamais pu réellement. Il est disponible sur presque toutes les plateformes imaginables et comporte plus de fonctionnalités que vous n'utiliserez probablement jamais.
Voici une copie d'une réponse que j'ai faite de ne question en double supprimée depuis lors à propos de Git vs. SVN (septembre 2009).
Mieux? Mis à part le lien habituel WhyGitIsBetterThanX , ils sont différents:
l'un est un VCS central basé sur une copie économique des branches et des tags, l'autre (Git) est un VCS distribué basé sur un graphique de révisions. Voir aussi concepts de base de VCS .
Cette première partie a généré des commentaires mal informés, prétendant que l'objectif fondamental des deux programmes (SVN et Git) est identique, mais qu'ils ont été mis en œuvre de manière tout à fait différente.
Pour clarifier la différence fondamentale entre SVN et Git , permettez-moi de reformuler:
SVN est la troisième implémentation d'un révision contrôle : RCS, puis CVS et enfin SVN gérer répertoires de données versionnées. SVN offre des fonctionnalités VCS (étiquetage et fusion), mais sa balise est juste une copie de répertoire (comme une branche, sauf que vous n'êtes pas "supposé" toucher à quoi que ce soit dans un répertoire de balises), et sa fusion est toujours compliquée, actuellement basée sur des méta -data ajouté pour rappeler ce qui a déjà été fusionné.
Git est un gestion de contenu de fichier (un outil conçu pour fusionner des fichiers), a évolué en un véritable système de contrôle de version , basé sur un DAG ( Directed Acyclic Graph ) de commits, où les branches font partie de l'historique des données (et non pas une donnée elle-même), et où les balises sont un vraies méta-données.
Dire qu'ils ne sont pas "fondamentalement" différents parce que vous pouvez réaliser la même chose, résoudre le même problème, c'est ... tout à fait faux à bien des égards.
- si vous avez beaucoup de fusions complexes, les faire avec SVN sera plus long et plus sujet aux erreurs. si vous devez créer plusieurs branches, vous devrez les gérer et les fusionner, encore beaucoup plus facilement avec Git qu'avec SVN, surtout si un grand nombre de fichiers sont impliqués (la vitesse devient alors importante)
- si vous avez des fusions partielles pour un travail en cours, vous profiterez de la zone de transfert Git (index) pour ne valider que ce dont vous avez besoin, cacher le reste et passer à une autre branche.
- si vous avez besoin de développement hors ligne ... eh bien avec Git, vous êtes toujours "en ligne", avec votre propre référentiel local, quel que soit le flux de travail que vous souhaitez suivre avec d'autres référentiels.
Néanmoins, les commentaires sur cette ancienne réponse (supprimée) insistaient:
VonC: Vous confondez différence fondamentale dans la mise en œuvre (les différences sont très fondamentales, nous sommes tout à fait d'accord sur cela) avec la différence de but.
Ce sont deux outils utilisés dans le même but: c’est pourquoi beaucoup d’équipes qui utilisaient auparavant SVN ont pu, avec beaucoup de succès, le laisser tomber en faveur de Git.
S'ils ne résolvent pas le même problème, cette substituabilité n'existerait pas.
, à laquelle j'ai répondu:
"substituabilité" ... terme intéressant ( tilisé dans la programmation informatique ).
Bien entendu, Git n’est guère un sous-type de SVN.
Vous pouvez obtenir les mêmes fonctionnalités techniques (balise, branche, fusion) avec les deux, mais Git ne vous gêne pas et vous permet de vous concentrer sur le contenu des fichiers , sans penser à l'outil lui-même.
Vous ne pouvez certainement pas (toujours) simplement remplacer SVN par Git "sans modifier aucune des propriétés souhaitables de ce programme (exactitude, tâche effectuée, ...)" (qui est une référence à la précédente définition de la substituabilité ):
- L'un est un outil de révision étendu, l'autre un véritable système de contrôle de version.
- L’un est adapté aux projets monolithiques de petite à moyenne envergure avec un flux de travail de fusion simple et (pas trop) de versions parallèles. SVN suffit pour cela et vous n’avez peut-être pas besoin de toutes les fonctionnalités de Git.
- L’autre permet de réaliser des projets de taille moyenne à grande basés sur plusieurs composants ( n rapport par composant ), avec un grand nombre de fichiers à fusionner entre plusieurs branches dans un flux de travail de fusion complexe, des versions parallèles dans des branches, des fusions ultérieures, etc. Vous pouvez le faire avec SVN, mais vous êtes beaucoup mieux avec Git.
SVN ne peut tout simplement pas gérer un projet de taille quelconque avec un workflow de fusion. Git peut.
Encore une fois, leur nature est fondamentalement différente (ce qui conduit ensuite à une mise en œuvre différente mais ce n’est pas le but).
L'un voit le contrôle de révision sous forme de répertoires et de fichiers, l'autre ne voit que le contenu du fichier (à tel point que les répertoires vides ne seront même pas enregistrés dans Git!).
L’objectif final général peut être identique, mais vous ne pouvez pas les utiliser de la même manière, ni résoudre le même type de problèmes (de portée ou de complexité).
2 avantages clés de SVN qui sont rarement cités:
Prise en charge de gros fichiers. En plus du code, j'utilise SVN pour gérer mon répertoire personnel. SVN est le seul VCS (distribué ou non) qui n’étouffe pas mes fichiers TrueCrypt (veuillez me corriger si un autre VCS gère efficacement les fichiers de plus de 500 Mo). En effet, les comparaisons diff sont diffusées (c’est un point essentiel). Rsync est inacceptable car ce n'est pas bidirectionnel.
Dépôt partiel (subdir), checkout/checkin. Mercurial et bzr ne supportent pas cela, et le support de git est limité. C’est mauvais dans un environnement d’équipe, mais inestimable si je veux vérifier quelque chose sur un autre ordinateur depuis mon répertoire personnel.
Juste mes expériences.
Après avoir fait plus de recherches et examiné ce lien: https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html
(Quelques extraits ci-dessous):
- C'est incroyablement rapide. Aucun autre SCM que j'ai utilisé n'a été en mesure de le suivre, et j'en ai beaucoup utilisé, y compris Subversion, Perforce, darcs, BitKeeper, ClearCase et CVS.
- C'est entièrement distribué. Le propriétaire du référentiel ne peut pas dicter mon travail. Je peux créer des branches et valider des modifications en étant déconnecté sur mon ordinateur portable, puis le synchroniser ultérieurement avec un nombre quelconque d'autres référentiels.
- La synchronisation peut se produire sur de nombreux supports. Un canal SSH, via HTTP via WebDAV, par FTP ou par envoi d’e-mails contenant des correctifs à appliquer par le destinataire du message. Un référentiel central n'est pas nécessaire, mais peut être utilisé.
- Les branches sont même moins chères que dans Subversion. Créer une branche est aussi simple que d’écrire un fichier de 41 octets sur le disque. Supprimer une branche est aussi simple que supprimer ce fichier.
- Contrairement à Subversion, les branches portent toute leur histoire. sans avoir à effectuer une copie étrange et parcourir la copie. Lors de l’utilisation de Subversion, j’ai toujours trouvé gênant de consulter l’historique d’un fichier sur une branche antérieure à la création de la branche. de #git: spearce: Je ne comprends rien au sujet de SVN dans la page. J'ai fait une branche i SVN et en parcourant l'historique, j'ai montré à l'ensemble de l'historique un fichier dans la branche
- La fusion de branches est plus simple et plus automatique dans Git. Dans Subversion, vous devez vous souvenir de la dernière révision à partir de laquelle vous avez fusionné pour pouvoir générer la commande de fusion correcte. Git le fait automatiquement et le fait toujours bien. Ce qui signifie qu'il y a moins de chance de se tromper en fusionnant deux branches.
- Les fusions de branches sont enregistrées dans le cadre de l'historique approprié du référentiel. Si je fusionne deux branches ensemble ou si je fusionne une branche dans son coffre d'origine, cette opération de fusion est enregistrée dans l'historique de repostory comme ayant été effectuée par moi, et à quel moment. Il est difficile de contester qui a effectué la fusion lorsque cela se trouve exactement dans le journal.
- La création d'un référentiel est une opération triviale: mkdir foo; cd foo; git init C'est ça. Ce qui signifie que je crée un référentiel Git pour tout, ces jours-ci. J'ai tendance à utiliser un référentiel par classe. La plupart de ces référentiels ont une taille de disque inférieure à 1 Mo car ils ne stockent que les notes de cours, les devoirs et mes réponses à LaTeX.
- Les formats de fichiers internes du référentiel sont incroyablement simples. Cela signifie que la réparation est très facile à faire, mais encore mieux parce que c'est si simple qu'il est très difficile de se corrompre. Je ne pense pas que quiconque ait jamais corrompu un référentiel Git. J'ai vu Subversion avec fsfs se corrompre. Et j'ai vu Berkley DB se corrompre trop souvent pour faire confiance à mon code pour le backend bdb de Subversion.
- Le format de fichier de Git est très bon pour la compression de données, malgré le fait qu'il s'agisse d'un format très simple. Le référentiel CVS du projet Mozilla est d’environ 3 Go; il s'agit d'environ 12 Go au format fsfs de Subversion. En Git c'est environ 300 MB.
Après avoir lu tout cela, je suis convaincu que Git est la voie à suivre (bien qu'un peu de courbe d'apprentissage existe). J'ai également utilisé Git et SVN sur les plates-formes Windows.
J'aimerais entendre ce que les autres ont à dire après avoir lu ce qui précède?
Je mettrais en place un dépôt Subversion. En procédant ainsi, les développeurs individuels peuvent choisir d'utiliser des clients Subversion ou Git (avec git-svn). Utiliser git-svn ne vous donne pas tous les avantages d'une solution complète Git, mais donne aux développeurs individuels un contrôle important sur leur propre flux de travail.
Je pense que le temps requis par Git sera aussi court sous Windows que sous Unix et Mac OS X (puisque vous l'avez demandé).
Subversion dispose d'excellents outils pour Windows, tels que l'intégration de TortoiseSVN pour Explorer et celle d'AnkhSVN pour Visual Studio.
La chose amusante est: J'héberge des projets dans Subversion Repos, mais vous y accédez via la commande Git Clone.
Veuillez lire Développer avec Git sur un projet de code Google
Bien que Google Code parle nativement Subversion, vous pouvez facilement utiliser Git pendant le développement. La recherche de "git svn" suggère que cette pratique est répandue et nous vous encourageons également à l'expérimenter.
Utiliser Git sur un référentiel Svn me procure des avantages:
- Je peux travailler distribué sur plusieurs machines, en les engageant et en les extrayant
- J'ai un référentiel central
backup/publicsvn pour que d'autres le consultent - Et ils sont libres d’utiliser Git pour leur propre compte.
Certainement svn, car Windows est au mieux un citoyen de seconde classe dans le monde de git (voir http://en.wikipedia.org/wiki/Git_ (logiciel) #Portability pour plus de détails).
UPDATE: Désolé pour le lien brisé, mais j'ai arrêté d'essayer de faire en sorte que SO fonctionne avec des URI contenant des parenthèses. [lien corrigé maintenant. -ed]
Si votre équipe est déjà familiarisée avec les logiciels de contrôle de version et de source tels que cvs ou svn, alors, pour un projet simple et de petite taille (comme vous le prétendez), je vous recommanderais de vous en tenir à SVN. Je suis vraiment à l'aise avec svn, mais pour le projet de commerce électronique que je réalise actuellement sur Django, j'ai décidé de travailler sur git (j'utilise git en mode svn, c'est-à-dire avec un référentiel centralisé que je pousse et tire afin de collaborer avec au moins un autre développeur). L'autre développeur est à l'aise avec SVN et, même si les expériences des autres peuvent différer, nous avons tous les deux beaucoup de mal à accepter Git pour ce petit projet. (Nous sommes tous les deux des utilisateurs inconditionnels de Linux, si cela compte vraiment.)
Votre kilométrage peut varier, bien sûr.
Vous ne répondez pas vraiment à votre question, mais si vous souhaitez bénéficier des avantages de Contrôle de révision distribué - cela ressemble à vous - et vous utilisez Windows, je pense que vous feriez mieux d'utiliser Mercurial plutôt que Git as Mercurial supporte beaucoup mieux Windows. Mercurial a aussi un port Mac.
Le point principal est que Git est un VCS distribué et que Subversion est centralisé. Les VCS distribués sont un peu plus difficiles à comprendre, mais présentent de nombreux avantages. Si vous n'avez pas besoin de ces avantages, Subversion sera peut-être le meilleur choix.
Une autre question est le support des outils. Quel VCS est mieux supporté par les outils que vous prévoyez d’utiliser?
EDIT: Il y a trois ans, j'ai répondu comme suit:
Et Git ne fonctionne pour le moment sur Windows que via Cygwin ou MSYS . Subversion supportait Windows depuis le début. Comme les solutions git pour Windows peuvent fonctionner pour vous, il peut y avoir des problèmes, car la plupart des développeurs de Git travaillent avec Linux et n’avaient pas la portabilité dans l’esprit depuis le début. Pour le moment, je préférerais Subversion pour le développement sous Windows. Dans quelques années, cela pourrait ne plus être pertinent.
Maintenant, le monde a un peu changé. Git a une bonne implémentation sur Windows maintenant. Bien que je n’ai pas fait de tests approfondis sur les fenêtres (car je n’utilise plus ce système), je suis assez confiant que tous les principaux VCS (SVN, Git, Mercurial, Bazaar) ont maintenant une implémentation correcte de Windows. Cet avantage pour SVN a disparu. Les autres points (centralisé vs distribué et la vérification de la prise en charge des outils) restent valables.
J'opterais pour SVN car il est plus répandu et mieux connu.
Je suppose que Git serait mieux pour les utilisateurs de Linux.
Cela revient à ceci:
Votre développement sera-t-il linéaire? Si c'est le cas, vous devriez vous en tenir à Subversion.
Si, en revanche, votre développement ne sera pas linéaire, ce qui signifie que vous devrez créer des branches pour différents changements, puis fusionner ces modifications dans la ligne de développement principale (connue sous le nom de branche principale de Git), puis Git le fera. BEAUCOUP plus pour vous.
J'utilise SVN depuis longtemps, mais chaque fois que j'utilisais Git, je sentais qu'il était beaucoup plus puissant, léger et qu'il nécessitait un peu d'apprentissage, mais qu'il était meilleur que SVN.
Ce que j’ai noté, c’est que chaque projet SVN, au fur et à mesure de sa croissance, devient un projet de très grande taille s’il n’est pas exporté. Là où, le projet GIT (avec les données Git) est très léger.
En SVN, j'ai traité avec des développeurs, des novices aux experts, et les novices et les intermédiaires semblent présenter des conflits de fichiers s'ils copient un dossier d'un autre projet SVN afin de le réutiliser. Tandis que, je pense, dans Git, vous copiez simplement le dossier et cela fonctionne, car Git n'introduit pas de dossiers .git dans tous ses sous-dossiers (comme le fait SVN).
Après avoir traité avec SVN pendant longtemps, je pense enfin à transférer mes développeurs et moi-même vers Git, car il est facile de collaborer et de fusionner le travail. De plus, l'un des grands avantages est que les modifications apportées à une copie locale peuvent être aussi bien engagées. souhaité, puis finalement poussé en une fois vers la branche sur le serveur, contrairement à SVN (où nous devons valider les modifications de temps en temps dans le référentiel sur le serveur).
Quelqu'un qui peut m'aider à décider si je devrais vraiment aller avec Git?
Git n'est pas encore supporté nativement sous Windows. Il est optimisé pour les systèmes Posix. Cependant, exécuter Cygwin ou MinGW vous permet d’exécuter Git avec succès.
De nos jours, je préfère Git à SVN, mais il faut un certain temps pour dépasser le seuil si vous venez de CVS, SVN Land.
Je choisirais probablement Git parce que j'estime que c'est beaucoup plus puissant que SVN. Il existe des services d'hébergement de code bon marché disponibles qui fonctionnent tout à fait pour moi - vous n'avez pas à faire de sauvegarde ni à effectuer aucun travail de maintenance - GitHub est le candidat le plus évident.
Cela dit, je ne connais rien à l'intégration de Visual Studio et des différents systèmes SCM. J'imagine que l'intégration avec SVN est nettement meilleure.
Il existe une vidéo intéressante sur YouTube à ce sujet. Cela vient de Linus Torvalds lui-même: Google Tech Talk: Linus Torvalds sur git
Puis-je développer la question et demander si Git fonctionne bien sous MacOS?
Répondre aux commentaires: Merci pour les nouvelles, j'avais hâte de l'essayer. Je l'installerai chez moi sur mon Mac.
avez-vous essayé Bzr ?
C'est assez bon, connonical (les gens qui font Ubuntu) l'ont fait parce qu'ils n'aimaient rien d'autre sur le marché ...
SVN semble être un bon choix sous Windows, comme l'a souligné d'autres personnes.
Si certains de vos développeurs souhaitent essayer GIT, il peut toujours utiliser GIT-SVN dans lequel le référentiel SVN est recréé dans un référentiel GIT. Ensuite, il devrait pouvoir travailler localement avec GIT, puis utiliser SVN pour publier ses modifications dans le référentiel principal.
Vous devez utiliser un DVCS, c'est comme un bond en avant dans la gestion des sources. Personnellement, j'utilise Monotone et son temps de développement accéléré est sans fin. Nous l'utilisons pour Windows, Linux et Mac et cela a été très stable. J'ai même buildbot en train de faire des builds nocturnes du projet sur chacune des plateformes.
DVCS en cours de distribution signifie généralement que vous allez créer un serveur central juste pour que les personnes puissent transmettre les modifications de et vers.