Pourquoi Git est-il meilleur que Subversion?

avec Git, vous pouvez faire pratiquement n'importe quoi hors ligne, parce que tout le monde a son propre dépôt.

faire des branches et fusionner entre les branches est vraiment facile.

même si vous n'avez pas de droits de propagation pour un projet, vous pouvez toujours avoir votre propre dépôt en ligne et publier des" requêtes push " pour vos correctifs. Tous ceux qui aiment vos patches peuvent les attirer dans leur projet, y compris les responsables officiels.

C'est trivial de bifurquer un projet, de le modifier, et de continuer à fusionner dans les bugfixes de la branche HEAD.

git fonctionne pour les développeurs du noyau Linux. Cela signifie qu'il est vraiment très rapide (elle doit être), et des échelles de milliers de contributeurs. Git utilise également moins d'espace (jusqu'à 30 fois moins d'espace pour le Mozilla référentiel).

Git est très souple, très TIMTOWTDI (Il n'y a plus d'une façon de le faire). Vous pouvez utiliser n'importe quel flux de travail que vous voulez, et git en charge.

enfin, il y a GitHub , un excellent site pour héberger vos dépôts Git.

les Inconvénients de Git:

• c'est beaucoup plus difficile à apprendre, parce que Git a plus de concepts et plus de commandes.
• les révisions n'ont pas de numéro de version comme dans subversion
• de nombreuses commandes Git sont cryptiques, et les messages d'erreur sont très peu conviviaux
• il manque une bonne GUI (comme le grand Tortoisvn )

autres réponses ont fait un bon travail d'explication des caractéristiques de base de Git (qui sont grandes). Mais il y a aussi tant de petits façons que Git se comporte mieux et aide à garder ma vie plus saine. Voici quelques petites choses:

1. Git a une commande "clean". SVN a désespérément besoin de cette commande, compte tenu de la fréquence à laquelle il dumpera des fichiers supplémentaires sur votre disque.
2. Git a la commande "bisect". C'est beau.
3. SVN creates .SVN directories dans chaque dossier (Git ne crée que un .répertoire git). Chaque script que vous écrivez, et chaque grep que vous faites, devra être écrit pour les ignorer .svn répertoires. Vous avez aussi besoin d'une commande entière ("svn export") juste pour obtenir une copie saine de vos fichiers.
4. dans SVN, chaque fichier & dossier peut provenir d'une révision ou d'une branche différente. Au début, ça semble agréable d'avoir cette liberté. Mais ce cela signifie en fait qu'il y a un million de façons différentes pour que votre caisse locale soit complètement foutue. (par exemple, si" svn switch " échoue à mi-chemin, ou si vous entrez une commande erronée). Et le pire, c'est que si vous vous retrouvez dans une situation où certains de vos fichiers viennent d'un endroit et d'autres d'un autre, le "statut svn" vous dira que tout est normal. Vous aurez besoin de faire "svn info" sur chaque fichier/répertoire pour découvrir à quel point les choses sont bizarres. Si "git le statut " vous dit que les choses sont normales, alors vous pouvez croire que les choses sont vraiment normales.
5. vous devez le dire à SVN chaque fois que vous déplacez ou supprimez quelque chose. Git va juste comprendre.
6. ignorer sémantique sont plus faciles dans Git. Si vous ignorez un modèle (tel que *.pyc), il sera ignoré pour les sous-répertoires all . (Mais si vous voulez vraiment ignorer quelque chose pour juste un répertoire, vous pouvez). Avec SVN, il semble qu'il n'y a pas de façon d'ignorer un motif sur tous les sous-répertoires.
7. un autre élément impliquant des fichiers ignorés. Git permet d'avoir des paramètres" privés " d'ignorer (en utilisant le fichier .git/info / exclude), qui n'affectera personne d'autre.

" Pourquoi Git est Mieux que X " décrit les avantages et les inconvénients de Git par rapport à d'autres Mec.

brièvement:

• Git pistes contenu plutôt que les fichiers
• les Branches sont légères et la fusion est facile , et je veux dire vraiment facile .
• il est distribué, fondamentalement, chaque référentiel est une branche. Il est beaucoup plus facile de développer simultanément et en collaboration Qu'avec Subversion, à mon avis. Il rend également hors ligne développement possible.
• Il n'impose pas de n'importe quel flux , comme on le voit sur ci-dessus site lié , il y a beaucoup de flux de travail possible avec Git. Un flux de travail de type Subversion est facilement imité.
• dépôts Git sont beaucoup plus plus petits dans la taille des fichiers que les dépôts Subversion. Il n'y a qu'un ".git" directory, par opposition à des dizaines de ".svn" dépôts (note Subversion 1.7 et plus utilise désormais un seul répertoire comme Git.)
• Le mise en scène quartier est génial, ça permet de voir les changements que vous devez vous engager, engager des changements partiels et de diverses autres choses.
• Cacher est inestimable lorsque vous faites un développement" chaotique", ou que vous voulez simplement corriger un bug alors que vous travaillez encore sur quelque chose d'autre (sur une branche différente).
• vous pouvez réécrire l'histoire , ce qui est idéal pour préparer des patch set et corriger vos erreurs ( avant vous publiez les commits)
• ... et un beaucoup plus.

il sont quelques inconvénients:

• il n'y a pas encore beaucoup de bonnes GUI pour cela. C'est nouveau et Subversion existe depuis beaucoup plus longtemps, c'est donc naturel car il y a quelques interfaces en développement. Certains bons comprennent TortoiseGit et GitHub pour Mac .
• des vérifications partielles/clones de dépôts ne sont pas possibles pour le moment (j'ai lu qu'il est en développement). Cependant, il y est sous-module de soutien. Git 1.7+ prend en charge éparses extractions .
• il pourrait être plus difficile d'apprendre, même si je n'ai pas trouvé que ce soit le cas (il ya environ un an). Git a récemment amélioré son interface et est très convivial.

dans l'usage le plus simpliste, Subversion et Git sont à peu près identiques. Il n'y a pas beaucoup de différence entre:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

et

git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

où Git brille vraiment est brancher et travailler avec d'autres personnes.

Google Tech Talk: Linus Torvalds on git

http://www.youtube.com/watch?v=4XpnKHJAok8

la page de comparaison de Wiki de Git

http://git.or.cz/gitwiki/GitSvnComparsion

Eh bien, il est distribué. Les Benchmarks indiquent que c'est beaucoup plus rapide (étant donné sa nature distribuée, les opérations comme les diffs et les logs sont toutes locales, donc bien sûr, c'est beaucoup plus rapide dans ce cas), et les dossiers de travail sont plus petits (ce qui me dépasse encore).

lorsque vous travaillez sur subversion, ou sur tout autre système de contrôle de révision client/serveur, vous créez essentiellement des copies de travail sur votre machine par les révisions check-out . Cela représente un instantané dans le temps de ce que le référentiel ressemble. Vous mettez à jour votre copie de travail via des mises à jour, et vous mettez à jour le dépôt via des propagations.

avec un contrôle de version distribué, vous n'avez pas de snapshot, mais plutôt l'intégralité du code. Tu veux faire une diff avec une version de 3 mois? Pas de problème, la version de 3 mois est toujours sur votre ordinateur. Cela ne signifie pas seulement les choses sont plus rapides, mais si vous êtes déconnecté de votre serveur central, vous pouvez toujours faites la plupart des opérations auxquelles vous êtes habitué. En d'autres termes, vous n'avez pas seulement un instantané d'une révision, mais l'ensemble de la base de code.

on pourrait penser que Git prendrait beaucoup de place sur votre disque dur, mais d'après quelques repères que j'ai vu, ça prend en fait moins. Ne me demandez pas comment. Il a été construit par Linus, il s'y connaît en systèmes de fichiers.

les points principaux que j'aime sur les DVCS sont ceux :

1. vous pouvez commettre des choses brisées. Ça n'a pas d'importance parce que les autres ne les verront pas avant que tu les publies. Le temps de publication est différent du temps de propagation.
2. pour cette raison, vous pouvez commettre plus souvent.
3. vous pouvez fusionner la fonctionnalité complète. Cette fonctionnalité aura sa propre branche. Toutes les propagations de cette branche seront liées à cette fonctionnalité. Vous peut le faire avec un CVCS mais avec DVCS son par défaut.
4. vous pouvez rechercher votre historique (trouver quand une fonction a changé )
5. Vous pouvez annuler un pull si quelqu'un bousiller le référentiel principal, vous n'avez pas besoin de corriger les erreurs. Juste effacer la fusion.
6. lorsque vous avez besoin d'un contrôle source dans un répertoire, faites : git init . et que vous pouvez vous engager, l'annulation des modifications, etc...
7. Il est rapide (même sur Windows )

la raison principale d'un projet relativement important est l'amélioration de la communication créée par le point 3. D'autres sont des bonus sympas.

la chose drôle est: J'héberge des projets dans les Repos Subversion, mais j'y accède via la commande git Clone.

s'il vous Plaît lire Développer avec Git sur un Google Code du Projet

bien que Google Code nativement parle Subversion, vous pouvez facilement utiliser Git au cours du développement. À la recherche de "git" svn " suggère que cette pratique est et nous vous encourageons aussi pour l'expérimenter.

utiliser Git sur un dépôt Svn me donne des avantages:

1. je peux travailler distribué sur plusieurs machines, engageant et tirant à partir de et à eux
2. j'ai un centrale backup/public dépôt svn pour les autres à vérifier
3. Et ils sont libres d'utiliser Git pour leur propre

toutes les réponses ici sont comme prévu, centré sur le programmeur, mais que se passe-t-il si votre entreprise utilise le contrôle de révision en dehors du code source? Il y a beaucoup de documents qui ne sont pas du code source qui bénéficient du contrôle de version, et qui devraient vivre près du code et pas dans un autre CMS. La plupart des programmeurs ne travaillent pas isolément - nous travaillons pour des entreprises en équipe.

dans cet esprit, comparez la facilité d'utilisation, à la fois dans l'outillage et la formation du client, entre Subversion et git. Je ne peux pas voir un scénario où n'importe quel système de contrôle de révision distribué sera plus facile à utiliser ou expliquer à un non-programmeur. J'aimerais qu'on me prouve que j'ai tort, parce qu'alors je pourrais évaluer git et avoir un espoir qu'il soit accepté par les gens qui ont besoin du contrôle de version qui ne sont pas programmeurs.

même alors, si la direction nous demandait pourquoi nous devrions passer d'un système centralisé à un système de contrôle de révision distribué, je serais difficile de donner une réponse honnête, parce que nous n'avons pas besoin il.

avertissement: je me suis intéressé à Subversion très tôt (vers v0.29) de toute évidence, je suis partial, mais les entreprises pour lesquelles j'ai travaillé depuis ce temps bénéficient de mon enthousiasme parce que j'ai encouragé et soutenu son utilisation. Je suppose que c'est comment ça se passe avec la plupart des logiciels d'entreprises. Avec autant de programmeurs sautant sur le train en marche, je me demande combien d'entreprises vont manquer sur le avantages d'utiliser le contrôle de version en dehors du code source? Même si vous avez des systèmes séparés pour différentes équipes, vous manquez certains des avantages, tels que l'intégration (unifiée) de suivi des problèmes, tout en augmentant la maintenance, le matériel et les exigences de formation.

Subversion est encore un système de contrôle de version beaucoup plus utilisé, ce qui signifie qu'il a une meilleure prise en charge des outils. Vous trouverez des plugins SVN matures pour presque n'importe quel IDE , et il y a de bonnes extensions d'Explorateur disponibles (comme TurtoiseSVN). A part ça, je suis d'accord avec Michael : Git n'est pas meilleur ou pire que Subversion, c'est différent.

une des choses à propos de SubVersion qui m'irrite est qu'elle place son propre dossier dans chaque répertoire d'un projet, alors que git n'en place qu'un dans le répertoire racine. Ce n'est pas que , mais des petites choses comme ça s'additionnent.

bien sûr, SubVersion a la tortue, ce qui est [habituellement] très agréable.

David Richards Wandisco Blog on Subversion /GIT

l'émergence de GIT a apporté avec elle une race de DVCS fondamentalistes – les "Gitterons" – qui pensent que tout autre que GIT est de la merde. Les Gitterons semblent penser que l'ingénierie logicielle se produit sur leur propre île et oublient souvent que la plupart des organisations n'emploient pas exclusivement des ingénieurs logiciels chevronnés. C'est ok, mais ce n'est pas comme ça que le reste du marché pense, et je suis heureux de le prouver: git, au dernier regard avait moins de trois pour cent du marché alors que Subversion a dans l'ordre de cinq millions d'utilisateurs et environ la moitié du marché global.

le problème que nous avons vu était que les Gitterons tiraient (pas cher) sur Subversion. Les Tweets comme "Subversion est donc [slow/merde/restrictive/ne sent pas très bon/me regarde d'une drôle de façon] et maintenant, j'ai GIT et [tout fonctionne dans ma vie/ma femme est tombée enceinte, j'ai eu une petite amie après 30 ans d'essai/j'ai gagné six fois en courant sur la table de blackjack]. Vous obtenez l'image.

Git rend également la ramification et la fusion très facile. Subversion 1.5 vient d'ajouter le suivi des fusions, mais Git est encore mieux. Avec Git branching est très rapide et bon marché. Cela rend la création d'une branche pour chaque nouvelle fonctionnalité plus faisable. Les dépôts Oh et Git sont très efficaces en termes d'espace de stockage par rapport à Subversion.

il s'agit de la facilité d'utilisation/étapes nécessaires pour faire quelque chose.

si je développe un seul projet sur mon PC/Ordinateur portable, git est mieux, car il est beaucoup plus facile à configurer et à utiliser. Vous n'avez pas besoin d'un serveur, et vous n'avez pas besoin de continuer à taper les URL du dépôt lorsque vous faites des fusions.

Si c'était juste 2 personnes, je dirais que git est aussi plus facile, parce que vous pouvez juste pousser et tirer de l'autre.

une fois que vous obtenez au-delà de cependant, j'opterais pour subversion, parce qu'à ce moment-là, vous devez configurer un serveur ou un emplacement "dédié".

vous pouvez le faire aussi bien avec Git qu'avec SVN, mais les avantages de Git sont compensés par la nécessité de faire des étapes supplémentaires pour se synchroniser avec un serveur central. Dans le SVN que vous venez de commettre. Dans git vous devez git commit, puis git push. L'étape supplémentaire est embêtant tout simplement parce que vous finissez par faire beaucoup.

SVN a également le bénéfice de de meilleurs outils GUI, mais l'écosystème git semble rattraper rapidement, donc je ne m'en soucierai pas à long terme.

Easy Git a une page agréable comparant l'utilisation réelle de Git et SVN qui vous donnera une idée de ce que Git peut faire (ou faire plus facilement) par rapport à SVN. (Techniquement, c'est basé sur Easy Git, qui est une enveloppe légère sur Git.)

Git et DVCS en général est grand pour les développeurs faisant beaucoup de codage indépendamment les uns des autres parce que chacun a sa propre branche. Si vous avez besoin d'un changement de quelqu'un d'autre, cependant, elle doit s'engager à son local de pensions et puis elle doit pousser la révision à vous ou vous devez tirer d'elle.

mon propre raisonnement me fait également penser que les DVCS rendent les choses plus difficiles pour L'assurance qualité et la gestion des versions si vous faites des choses comme les versions centralisées. Quelqu'un doit être responsable de faire ce push/pull à partir du dépôt de tout le monde, de résoudre tous les conflits qui auraient été résolus au moment de la propagation initiale avant, puis de faire la compilation, et ensuite d'avoir tous les autres développeurs re-synchroniser leurs repos.

tout cela peut être traité avec des processus humains, bien sûr; DVCS vient de casser quelque chose qui a été corrigé par le contrôle de version centralisé afin de fournir de nouvelles commodités.

j'aime git parce qu'il aide en fait développeur de communication à développeur sur une moyenne à grande équipe. En tant que système de contrôle de version distribué, grâce à son système push/pull, il aide les développeurs à créer un code source eco-system qui aide à gérer un grand nombre de développeurs travaillant sur un seul projet.

par exemple, dites que vous faites confiance à 5 développeurs et que vous ne retirez que les codes de leur dépôt. Chacun de ces développeurs a son propre réseau de confiance d'où ils pull codes. Ainsi, le développement est basé sur ce tissu de confiance de développeurs où la responsabilité du code est partagée entre la communauté de développement.

bien sûr il y a d'autres avantages qui sont mentionnés dans d'autres réponses ici.

quelques réponses ont fait allusion à ceux-ci, mais je tiens à rendre 2 points explicites:

1) la capacité de procéder à des propagations sélectives (par exemple, git add --patch ). Si votre répertoire de travail contient plusieurs modifications qui ne font pas partie de la même modification logique, Git rend très facile de faire une propagation qui n'inclut qu'une partie des modifications. Avec Subversion, c'est difficile.

2) la capacité de s'engager sans rendre le changement public. Dans Subversion, tout commit est immédiatement public, et donc irrévocable. Cela limite grandement la capacité du développeur à "s'engager au début, commettent souvent".

Git est plus qu'un simple VCS, c'est aussi un outil pour développer des patches. Subversion est simplement un VCS.

je pense que Subversion va bien.. jusqu'à ce que tu commences à fusionner.. ou faire quelque chose de compliqué.. ou faire quelque chose que Subversion pense être compliqué (comme faire des requêtes pour savoir quelles branches ont modifié un fichier particulier, d'où provient un changement en fait , détecter la copie et les pâtes, etc.)...

Je ne suis pas d'accord avec la réponse gagnante, disant le principal avantage de GIT est le travail hors ligne - il est certainement utile, mais il est plus comme un extra pour mon cas d'utilisation. SVK peut travailler hors ligne aussi, mais il n'y a pas de question pour moi dans lequel investir mon temps d'apprentissage).

c'est juste que C'est incroyablement puissant et rapide, et bien après avoir utilisé les concepts - très utile (oui, dans ce sens: user friendly).

pour plus de détails sur une histoire de fusion, voir ce : utilisant git-svn (ou similaire) * juste* pour aider avec une fusion svn?

grâce au fait qu'il n'a pas besoin de communiquer constamment avec un serveur central, à peu près toutes les commandes s'exécutent en moins d'une seconde (évidemment git push/pull/fetch sont plus lents simplement parce qu'ils doivent initialiser les connexions SSH). Brancher est beaucoup plus facile (une simple commande à la branche, une simple commande pour fusionner)

j'aime absolument être capable de gérer les branches locales de mon code source dans Git sans embrouiller l'eau du dépôt central. Dans de nombreux cas, je vais vérifier le code du serveur Subversion et lancer un dépôt Git local juste pour pouvoir le faire. C'est également génial que l'initialisation d'un dépôt Git ne pollue pas le système de fichiers avec un tas d'ennuyant .svn dossiers partout.

et en ce qui concerne le soutien d'outil de Windows, TortoiseGit gère les bases très bien, mais je préfère quand même la ligne de commande sauf si je veux voir le journal. J'aime vraiment la façon dont la tortue {Git / SVN} aide à la lecture des logs de propagation.

C'est la mauvaise question à poser. Il est trop facile de se concentrer sur les verrues de git et de formuler un argument sur la raison pour laquelle subversion est ostensiblement meilleure, du moins pour certains cas d'utilisation. Le fait que git a été conçu à l'origine comme un ensemble de construction de contrôle de version de bas niveau et dispose d'une interface Linux baroque axée sur les développeurs rend plus facile pour les guerres saintes d'obtenir la traction et la légitimité perçue. Les partisans de Git tapent le tambour avec des millions d'avantages de flux de travail, qui svn les gars proclament inutile. Très vite, tout le débat est organisé comme centralisé vs distribué, ce qui sert les intérêts de la communauté des outils de svn d'entreprise. Ces entreprises, qui publient généralement les articles les plus convaincants sur la supériorité de subversion dans l'entreprise, dépendent de l'insécurité perçue de git et de la préparation de svn à l'entreprise pour le succès à long terme de leurs produits.

Mais voici le problème: Subversion est une sans issue architecturale .

alors que vous pouvez prendre git et construire un remplacement de subversion centralisé assez facilement, bien qu'il soit présent depuis plus de deux fois plus de temps que svn n'a jamais été capable d'obtenir même un suivi basique des fusions aussi proche que dans Git. L'une des raisons fondamentales en est la décision de concevoir des branches identiques à des répertoires. Je ne sais pas pourquoi ils sont allés de cette façon à l'origine, il fait certainement partial checkouts très simple. Malheureusement, il rend également impossible de suivre l'histoire correctement. De toute évidence, vous êtes censés utiliser les conventions de mise en page des dépôts subversion pour séparer les branches des répertoires réguliers, et svn utilise certaines heuristiques pour faire fonctionner les choses dans les cas d'utilisation quotidienne. Mais tout cela ne fait que masquer une très mauvaise et très limitée décision de conception de bas niveau. Être capable de faire une diff à l'échelle du dépôt (plutôt qu'une diff à l'échelle du répertoire) est une fonctionnalité de base et critique pour un contrôle de version et simplifie considérablement les internes, ce qui permet de construire des fonctionnalités plus intelligentes et utiles sur le dessus de celui-ci. Vous pouvez voir dans les efforts qui ont été déployés pour étendre subversion, et pourtant combien loin derrière elle se trouve la récolte actuelle de VCSes modernes en termes d'opérations fondamentales comme la résolution de fusion.

maintenant voici mon conseil sincère et agnostique pour quiconque croit encore que Subversion est assez bon pour le futur prévisible:

Subversion ne rattrapera jamais les nouvelles races de VCSes qui ont appris des erreurs des RCS et des CVS; c'est une impossibilité technique à moins qu'ils ne rééquipent le modèle de dépôt à partir de la base, mais alors ce ne serait pas vraiment svn n'est-ce pas? Peu importe à quel point vous pensez que vous ne possédez pas les capacités d'un VCS Moderne, votre ignorance ne vous protégera pas des pièges de la Subversion, dont beaucoup sont des situations qui sont impossibles ou faciles à résoudre dans d'autres systèmes.

il est extrêmement rare que l'infériorité technique d'une solution soit aussi évidente qu'elle l'est avec svn, certainement Je ne dirais jamais une telle opinion sur win-vs-linux ou emacs-vs-vi, mais dans ce cas, c'est tellement clair, et le contrôle des sources est un outil si fondamental dans l'arsenal du développeur, que je pense qu'il doit être déclaré sans équivoque. Indépendamment de la nécessité d'utiliser svn pour des raisons d'organisation, j'implore tous les utilisateurs de svn de ne pas laisser leur esprit logique construire une fausse croyance que les VCSes plus modernes ne sont utiles que pour les grands projets open-source. Quelle que soit la nature de votre travail de développement, si vous êtes un programmeur, vous serez plus efficace programmeur si vous apprenez à utiliser mieux conçu VCSes, qu'il s'Git, Mercurial, Darcs, ou beaucoup d'autres.

Subversion est très facile à utiliser. Je n'ai jamais trouvé ces dernières années un problème ou que quelque chose ne fonctionne pas comme prévu. Il existe également de nombreux outils D'interface graphique et le soutien à L'intégration de SVN est important.

avec Git vous obtenez un VCS plus flexible. Vous pouvez l'utiliser de la même manière que SVN avec un dépôt distant où vous propagez toutes les modifications. Mais vous pouvez également l'utiliser la plupart du temps hors ligne et seulement pousser les changements de temps en temps vers le dépôt distant. Mais Git est plus complexe et a une courbe d'apprentissage plus raide. Je me suis retrouvé dans la première fois à commettre des branches erronées, créer des branches indirectement ou obtenir des messages d'erreur avec peu d'informations sur l'erreur et où je dois rechercher avec Google pour obtenir de meilleures informations. Certaines choses faciles comme la substitution de marqueurs ($Id$) ne fonctionne pas, mais GIT a un mécanisme de filtrage et de crochet très flexible pour fusionner ses propres scripts et donc vous obtenez toutes les choses dont vous avez besoin et plus, mais il a besoin de plus de temps et de la lecture de la documentation;)

si vous travaillez principalement hors ligne avec votre dépôt local, vous n'avez aucune sauvegarde si quelque chose est perdu sur votre machine locale. Avec SVN, vous travaillez principalement avec un dépôt distant qui est aussi le même moment que votre sauvegarde sur un autre serveur... Git peut fonctionner de la même manière, mais ce N'était pas le but principal de Linus d'avoir quelque chose comme SVN2. Il a été conçu pour les développeurs du noyau Linux et les besoins d'un système de contrôle de version distribué.

est-ce que Git est mieux que SVN? Les développeurs qui n'ont besoin que d'un historique de version et d'un mécanisme de sauvegarde ont une vie facile avec SVN. Les développeurs travaillant souvent avec des branches, testant plus de versions en même temps ou travaillant principalement hors ligne peuvent bénéficier des fonctionnalités de Git. Il y a des fonctionnalités très utiles comme le rangement qui ne sont pas disponibles avec SVN et qui peuvent rendre la vie plus facile. Mais de l'autre côté, tous les gens n'auront pas besoin de toutes les fonctionnalités. Donc je ne peux pas voir les morts de SVN.

Git besoins d'une meilleure documentation et les rapports d'erreur doit être des plus utiles. De plus, les interfaces graphiques utiles existantes ne le sont que rarement. Cette fois, je n'ai trouvé Qu'une interface graphique pour Linux avec la prise en charge de la plupart des fonctionnalités Git (Git-cola). Eclipse intégration fonctionne, mais son pas officiel publié et il n'y a pas de site de mise à jour officielle (seulement certains site de mise à jour externe avec des constructions périodiques à partir du tronc http://www.jgit.org/updates ) Donc, la façon la plus préférée d'utiliser Git ce jours est la ligne de commande.

Eric Sink de SourceGear a écrit une série d'articles sur les différences entre les systèmes de contrôle de version distribués et non distribués. Il compare les avantages et les inconvénients des systèmes de contrôle de versions les plus populaires. Très intéressant à lire.

Les Articles peuvent être trouvés sur son blog, www.ericsink.com :

• lire les Diffs

• Git est le C de la Version des Outils de Contrôle

• Sur Git est un manque de respect pour l'immuabilité et les Meilleures Pratiques pour un DVCS

• DVCS and DAGs, Part 1

• DVCS and DAGs, Part 2

• DVCS et de Suivi des Bogues

• Fusion de l'Histoire, les Dag et Darcs

• pourquoi Git est-il si rapide?

• Mercurial, Subversion, and Wesley Snipes

pour les personnes à la recherche d'une bonne Git GUI, Syntevo SmartGit pourrait être une bonne solution. Son propriétaire, mais libre pour une utilisation non-commerciale, Fonctionne sur Windows / Mac / Linux et supporte même SVN en utilisant une sorte de pont git-svn, je pense.

http://subversion.wandisco.com/component/content/article/1/40.html

je pense qu'il est assez sûr de dire que parmi les développeurs, le SVN Vs. L'argument de Git fait rage depuis un certain temps maintenant, chacun ayant son propre point de vue sur ce qui est mieux. Cela a même été évoqué dans les questions lors de notre webinaire sur Subversion en 2010 et au-delà.

Hyrum Wright, notre directeur de L'Open Source et le Président pour la société Subversion, il est question des différences entre Subversion et Git, ainsi que d'autres systèmes de contrôle de Version distribués (DVCS).

il parle également des changements à venir dans Subversion, tels que la copie de travail de la prochaine génération (WC-NG), qui, selon lui, obligera un certain nombre d'utilisateurs Git à se convertir de nouveau en Subversion.

regardez sa vidéo et faites-nous savoir ce que vous en pensez en commentant sur ce blog, ou en postant dans nos forums. L'inscription est simple et ne prendra qu'un instant!

Git dans Windows est assez bien supporté maintenant.

Check out GitExtensions = http://code.google.com/p/gitextensions /

et le manuel pour une meilleure expérience Windows Git.

ces derniers temps, je me suis installé dans le Git land, et je l'aime bien pour des projets personnels, mais je ne serais pas encore en mesure de passer de projets de travail à lui de Subversion étant donné le changement dans la façon de penser exigé du personnel, sans aucun avantage urgent. En outre, le plus grand projet que nous gérons en interne est extrêmement dépendant de svn:externals qui, de ce que j'ai vu jusqu'à présent, ne fonctionne pas si bien et de façon transparente en Git.

tout d'abord, le contrôle de version concurrent semble être un problème facile à résoudre. Il n'est pas tout. De toute façon...

SVN n'est pas très intuitif. Git est encore pire. [sarcastique-spéculation] cela pourrait être parce que les développeurs, qui aiment les problèmes difficiles comme le contrôle de version concurrent, n'ont pas beaucoup d'intérêt à faire une bonne interface utilisateur. [/sarcastique-spéculation]

les supporters de SVN pensent qu'ils n'ont pas besoin d'un système de contrôle de version distribué. j'ai pensé que trop. mais maintenant que nous utilisons Git exclusivement, je suis un croyant. Maintenant, le contrôle de version Fonctionne pour moi et l'équipe/projet au lieu de simplement travailler pour le projet. Quand j'ai besoin d'une branche, je branche. Parfois, c'est une branche qui a une succursale sur le serveur, et parfois ça ne marche pas. Sans parler de tous les autres avantages que je vais devoir étudier sur (en partie grâce à l'absence obscure et absurde D'UI qui est un système de contrôle de version moderne).

pourquoi je pense que Subversion est mieux que Git (du moins pour les projets sur lesquels je travaille), principalement en raison de sa facilité d'utilisation et de la simplification du flux de travail:

http://www.databasesandlife.com/why-subversion-is-better-than-git /