Pourquoi est-Git mieux que Subversion?

voix
393

J'utilise Subversion pour quelques années et après avoir utilisé SourceSafe , j'adore Subversion. Combiné avec TortoiseSVN , je ne peux pas vraiment imaginer comment il pourrait être mieux.

Pourtant , il y a un nombre croissant de développeurs affirmant que Subversion a des problèmes et que nous devrions passer à la nouvelle génération de systèmes de contrôle de version distribuée, comme Git .

Comment améliorer Git sur Subversion?

Créé 03/08/2008 à 23:38
source utilisateur
Dans d'autres langues...                            


30 réponses

voix
548

Git est pas mieux que Subversion. Mais est aussi pire. C'est différent.

La principale différence est qu'il est décentralisé. Imaginez que vous êtes un développeur sur la route, vous développez sur votre ordinateur portable et que vous voulez avoir le contrôle de la source afin que vous pouvez revenir en arrière 3 heures.

Avec Subversion, vous avez un problème: le dépôt SVN peut être dans un endroit que vous ne pouvez pas atteindre (dans votre entreprise, et vous n'avez pas Internet à l'heure actuelle), vous ne pouvez pas commettre. Si vous souhaitez effectuer une copie de votre code, vous devez littéralement copier / coller.

Avec Git, vous n'avez pas ce problème. Votre copie locale est un dépôt, et vous pouvez engager et obtenir tous les avantages du contrôle de code source. Lorsque vous regagnez la connectivité au référentiel principal, vous pouvez vous engager contre elle.

Cela ressemble bien au début, mais juste garder à l'esprit la complexité ajoutée à cette approche.

Git semble être la chose « nouveau, brillant, cool ». Il est absolument pas mauvais (il y a une raison Linus a écrit pour le développement du noyau Linux après tout), mais je pense que beaucoup de gens sauter dans le train « contrôle de code source distribué » juste parce qu'il est nouveau et est écrit par Linus Torvalds, sans réellement savoir pourquoi / si elle est mieux.

Subversion a des problèmes, mais le fait Git, Mercurial, CVS, TFS ou autre.

Edit: Donc , cette réponse est maintenant un an et génère encore beaucoup upvotes, donc je pensais que je vais ajouter quelques explications. L'année dernière depuis la rédaction de ce, Git a gagné beaucoup d'élan et de soutien, en particulier depuis des sites comme GitHub a vraiment décollé. J'utilise à la fois Git et Subversion de nos jours et je voudrais partager une idée personnelle.

tout d'abord Git peut être vraiment déroutant au premier abord quand le travail décentralisé. Qu'est-ce une télécommande? et comment configurer correctement le dépôt initial? sont deux questions qui surgissent au début, surtout par rapport à de simples « svnadmin create » de SVN, « init git » Git peut prendre les paramètres --bare et --shared qui semble être la manière « appropriée » pour mettre en place un système centralisé dépôt. Il y a des raisons à cela, mais il ajoute la complexité. La documentation de la commande « caisse » est très déroutant pour les changements sur - la « bonne » façon semble être « clone git », tandis que « git checkout » semble changer de branches.

Git brille vraiment quand vous êtes décentralisé. J'ai un serveur à la maison et un ordinateur portable sur la route, et SVN ne fonctionne pas bien tout simplement ici. Avec SVN, je ne peux pas avoir le contrôle de source locale si je ne suis pas connecté au référentiel (Oui, je sais SVK ou sur les moyens de copier le repo). Avec Git, qui est le mode par défaut de toute façon. Il est une commande supplémentaire si (git commit engage localement, alors que maître d'origine git push pousse la branche maître à la « origine » à distance nommée).

Comme dit ci-dessus: Git ajoute à la complexité. Deux modes de création de référentiels, la caisse contre clone, engager contre pression ... Vous devez savoir quelles commandes fonctionnent localement et qui travaillent avec « le serveur » (je suppose que la plupart des gens encore comme un « maître-dépôt » central ).

En outre, l'outillage est encore insuffisante, au moins sous Windows. Oui, il y a un Visual Studio AddIn, mais je l'utilise encore bash git avec msysgit.

SVN a l'avantage qu'il est beaucoup plus simple à apprendre: Il est votre référentiel, toutes les modifications à son égard, si vous savez comment créer, engager et de départ et vous êtes prêt à aller et peut pick-up des choses comme branchement, mise à jour, etc. plus tard sur.

Git a l'avantage qu'il est beaucoup mieux si certains développeurs ne sont pas toujours connectés au référentiel maître. Aussi, il est beaucoup plus rapide que SVN. Et d'après ce que je l'entends, le soutien et la fusion est essaimer beaucoup mieux (ce qui est à prévoir, car ce sont les raisons fondamentales il a été écrit).

Cela explique aussi pourquoi il gagne tellement buzz sur Internet, comme Git est parfaitement adapté pour les projets Open Source: Juste Fork il, engage vos modifications à votre propre fourchette, puis demander au responsable du projet initial pour tirer vos modifications. Avec Git, cela fonctionne. Vraiment, essayez-le sur Github, il est magique.

Ce que je vois aussi sont Git-SVN ponts: Le dépôt central est un repo Subversion, mais les développeurs travaillent localement avec Git et le pont pousse alors les changements à SVN.

Mais même avec cet ajout long, je maintiens toujours mon message de base: Git n'est pas meilleur ou pire, il est juste différent. Si vous avez le besoin de « contrôle hors ligne Source » et la volonté de passer un peu de temps d'apprentissage, ce qui est fantastique. Mais si vous avez un contrôle de code source strictement centralisée et / ou luttez pour introduire le contrôle Source en premier lieu parce que vos collègues ne sont pas intéressés, la simplicité et un excellent outillage (au moins sous Windows) de briller SVN.

Créé 03/08/2008 à 23:45
source utilisateur

voix
145

Avec Git, vous pouvez faire pratiquement tout ce que hors ligne, car tout le monde a son propre référentiel.

Faire des branches et la fusion entre les branches est vraiment facile.

Même si vous ne disposez pas d'engager des droits pour un projet, vous pouvez toujours avoir votre propre référentiel en ligne et publier « demandes push » pour vos patches. Tout le monde qui aime vos patches peut les tirer dans leur projet, y compris les mainteneurs officiels.

Il est trivial à la fourchette d'un projet, de le modifier, et toujours garder la fusion des corrections de bugs de la branche HEAD.

Git travaille pour les développeurs du noyau Linux. Cela signifie qu'il est très rapide (il doit être), et des échelles à des milliers de contributeurs. Git utilise également moins d'espace (jusqu'à 30 fois moins d'espace pour le dépôt Mozilla).

Git est très flexible, très TIMTOWTDI (Il y a plus d'une façon de le faire). Vous pouvez utiliser tous les flux de travail que vous voulez, et Git soutenir.

Enfin, il y a GitHub , un excellent site pour l' hébergement de vos dépôts Git.

Git: Inconvénients de

  • il est beaucoup plus difficile à apprendre, parce que Git a plus de concepts et d'autres commandes.
  • les révisions ne sont pas les numéros de version comme dans la subversion
  • de nombreuses commandes de Git sont énigmatiques, et les messages d'erreur sont très peu convivial
  • il manque une bonne interface graphique (comme le grand TortoiseSVN )
Créé 04/08/2008 à 01:24
source utilisateur

voix
110

D' autres réponses ont fait un bon travail d'expliquer les caractéristiques de base de Git (qui sont grands). Mais il y a aussi tant de petites façons que Git comporte mieux et aide à garder ma vie plus sain d' esprit. Voici quelques - unes des petites choses:

  1. Git a une commande « propre ». SVN a désespérément besoin de cette commande, compte tenu de la fréquence à laquelle il videra des fichiers supplémentaires sur votre disque.
  2. Git a la commande « bissectrice ». C'est bien.
  3. SVN crée des répertoires .svn dans chaque dossier unique (Git crée seulement un répertoire .git). Chaque script que vous écrivez et chaque grep que vous faites, devront être écrit pour ignorer ces répertoires .svn. Vous devez également une commande entière ( « svn export ») juste pour obtenir une copie saine de vos fichiers.
  4. Dans SVN, chaque fichier et dossier peuvent provenir d'une autre révision ou une succursale. Tout d'abord, il semble agréable d'avoir cette liberté. Mais ce que cela signifie en fait est qu'il ya un million de façons différentes pour votre caisse locale d'être complètement foiré. (Par exemple, si « svn switch » échoue à mi-chemin, ou si vous entrez dans une mauvaise commande). Et le pire est: si jamais vous entrez dans une situation où certains de vos fichiers viennent d'un endroit, et certains d'entre eux d'une autre, le « statut svn » vous dira que tout est normal. Vous aurez besoin de faire « info svn » sur chaque fichier / répertoire pour découvrir comment les choses sont bizarres. Si « git status » vous dit que les choses sont normales, vous pouvez faire confiance que les choses sont vraiment normal.
  5. Vous devez dire SVN chaque fois que vous déplacez ou supprimez quelque chose. Git juste comprendre.
  6. Sémantique Ignore sont plus faciles dans Git. Si vous ignorez un motif ( par exemple * .pyc), il sera ignoré pour tous les sous - répertoires. (Mais si vous voulez vraiment ignorer quelque chose pour un seul répertoire, vous pouvez). Avec SVN, il semble qu'il n'y a pas moyen facile d'ignorer un modèle dans tous les sous - répertoires.
  7. Un autre élément impliquant ignorer les fichiers. Git permet d'avoir ignorer les paramètres « privé » (en utilisant le fichier .git / info / exclure), qui n'affectera pas quelqu'un d'autre.
Créé 26/09/2008 à 01:18
source utilisateur

voix
56

« Pourquoi Git est meilleur que X » décrit les différents avantages et les inconvénients de Git vs autres ajouts cimentaires.

Brièvement:

  • Git suit le contenu plutôt que des fichiers
  • Les branches sont légères et la fusion est facile , et je veux dire vraiment facile .
  • Il est distribué, essentiellement chaque dépôt est une branche. Il est beaucoup plus facile de développer simultanément et en collaboration qu'avec Subversion, à mon avis. Il est également hors - ligne développement possible.
  • Il n'impose pas de flux de travail , comme on le voit sur le site lié ci - dessus , il y a beaucoup de flux de travail possibles avec Git. Un flux de travail de type Subversion est facilement imitée.
  • Dépôts Git sont beaucoup plus petits en taille de fichier que les dépôts Subversion. Il n'y a qu'un seul répertoire « .git », par opposition à des dizaines de dépôts de « svn » (note Subversion 1.7 et supérieur utilise maintenant un seul répertoire comme Git.)
  • La mise en scène espace est impressionnant, il vous permet de voir les changements que vous commettrez, livrez des changements partiels et faire diverses autres choses.
  • Stashing est inestimable quand vous faites du développement « chaotique », ou simplement pour corriger un bug pendant que vous travaillez toujours sur quelque chose d' autre (sur une autre branche).
  • Vous pouvez réécrire l' histoire , ce qui est idéal pour la préparation d' ensembles de patch et de fixer vos erreurs ( avant de publier les commits)
  • ... et beaucoup plus.

Il y a quelques inconvénients:

  • Il n'y a pas beaucoup de bons pour GUIs encore. Il est nouveau et Subversion a été autour pour beaucoup plus longtemps, donc ce qui est naturel car il y a quelques interfaces dans le développement. Quelques bons comprennent TortoiseGit et GitHub pour Mac .
  • checkouts / clones partiels de dépôts ne sont pas possibles au moment (je lis qu'il est en développement). Cependant, il y a un soutien sous-module. Git 1.7+ prend en charge les extractions éparses .
  • Il pourrait être plus difficile à apprendre, même si je ne trouve pas que ce soit le cas (il y a environ un an). Git a récemment amélioré son interface et est tout à fait conviviale utilisateur.

Dans l'utilisation la plus simpliste, Subversion et Git sont à peu près les mêmes. 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 essaimer et de travailler avec d'autres personnes.

Créé 10/02/2009 à 05:18
source utilisateur

voix
54

Google Tech Talk: Linus Torvalds sur git

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

La page de comparaison de Git Wiki

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

Créé 03/08/2008 à 23:44
source utilisateur

voix
26

Eh bien, il est distribué. Points de référence indiquent qu'il est beaucoup plus rapide (compte tenu de sa nature distribuée, des opérations telles que les diffs et les journaux sont locaux si bien sûr, il est plus rapide blazingly dans ce cas), et les dossiers de travail sont plus petits (qui souffle encore l'esprit).

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

Avec un contrôle de version distribuée, vous ne disposez pas d'un cliché, mais l'ensemble du code de base. Vous voulez faire un diff avec la version 3 mois? Pas de problème, l'ancienne version de 3 mois est toujours sur votre ordinateur. Cela ne signifie pas seulement les choses sont beaucoup plus rapides, mais si vous êtes déconnecté de votre serveur central, vous pouvez toujours faire un grand nombre des opérations que vous êtes habitué. En d'autres termes, vous n'avez pas seulement un instantané d'une révision donnée, mais l'ensemble du code de base.

On pourrait penser que Git prendrait un tas d'espace sur votre disque dur, mais à partir d'un couple de référence que je l'ai vu, il faut en fait moins. Ne me demandez pas comment. Je veux dire, il a été construit par Linus, il sait une chose ou deux à propos des systèmes de fichiers, je suppose.

Créé 03/08/2008 à 23:47
source utilisateur

voix
22

Les principaux points que j'aime DVCS sont celles-ci:

  1. Vous pouvez commettre des choses brisées. Il n'a pas d'importance parce que d'autres peuples ne les verront pas jusqu'à ce que vous publiez. L'heure de publication est différente validation de temps.
  2. En raison de cela, vous pouvez engager plus souvent.
  3. Vous pouvez fusionner functionnality complète. Cette fonctionnalité aura sa propre branche. Tous les commits de cette branche seront liés à cette fonctionnalité. Vous pouvez le faire avec toutefois RCV avec DVCS sa valeur par défaut.
  4. Vous pouvez rechercher votre histoire (trouver lorsqu'une fonction a changé)
  5. Vous pouvez annuler une traction si quelqu'un bousiller le dépôt principal, vous n'avez pas besoin de corriger les erreurs. Il suffit de supprimer la fusion.
  6. Lorsque vous avez besoin d'un contrôle de code source dans un répertoire faire: git init. et vous pouvez vous engager, d'annuler des modifications, etc ...
  7. Il est rapide (même sous Windows)

La raison principale d'un projet relativement grande est la meilleure communication créé par le point 3. D'autres sont des bonus agréables.

Créé 04/09/2008 à 12:06
source utilisateur

voix
15

La chose drôle est: je serai l'hôte des projets dans Subversion Repos, mais leur accès via la commande Clone Git.

S'il vous plaît lire Développer avec Git sur un code Google projet

Bien que Google Code parle en mode natif Subversion, vous pouvez facilement utiliser Git au cours du développement. Recherche de « svn git » suggère que cette pratique est très répandue, et nous encourageons aussi vous à expérimenter avec elle.

En utilisant Git sur un référentiel Svn me donne des avantages:

  1. Je peux travailler distribué sur plusieurs machines, et en tirant commiting de et pour les
  2. J'ai un central backup/public dépôt svn pour d' autres à vérifier
  3. Et ils sont libres d'utiliser Git pour leur propre
Créé 02/10/2008 à 14:05
source utilisateur

voix
11

Toutes les réponses ici sont comme prévu, centrée sur le programmeur, mais ce qui se passe 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 le code source qui bénéficient du contrôle de version, et doit vivre à proximité de code et pas dans un autre CMS. La plupart des programmeurs ne fonctionnent pas en vase clos - nous travaillons pour les entreprises dans le cadre d'une équipe.

Avec cela à l' esprit, comparer la facilité d'utilisation, à la fois l' outillage client et la formation, entre Subversion et git. Je ne vois pas un scénario où tout système de contrôle de révision distribué va être plus facile à utiliser ou expliquer à un non-programmeur. J'aimerais me tromper, parce que je serais en mesure d'évaluer git et ont en fait un espoir de celui - ci soit acceptée par les personnes qui ont besoin de contrôle de version qui ne sont pas des programmeurs.

Même alors, si demandé par la direction pourquoi nous devons passer d'un système centralisé à un système de contrôle de révision distribué, je serait difficile de donner une réponse honnête, parce que nous ne avons pas besoin.

Disclaimer: Je suis intéressé à Subversion tôt (autour v0.29) si évidemment je suis partial, mais les entreprises que j'ai travaillé depuis ce temps profitent de mon enthousiasme parce que je l'ai encouragé et soutenu son utilisation. Je soupçonne que c'est la façon dont cela se produit avec la plupart des entreprises de logiciels. Avec tant de programmeurs de sauter sur le train en marche git, je me demande combien d'entreprises vont manquer sur les avantages de l'utilisation de contrôle de version en dehors du code source? Même si vous avez des systèmes séparés pour les différentes équipes, vous êtes absent sur certains des avantages, tels que (unifiée) l'intégration de suivi des problèmes, tout en augmentant la maintenance, le matériel et les besoins en formation.

Créé 13/10/2009 à 08:01
source utilisateur

voix
9

Subversion est encore un système de contrôle de version beaucoup plus utilisé, ce qui signifie qu'il a un meilleur support de l' outil. Vous trouverez des plugins SVN matures pour presque tous les IDE , et il y a de bonnes extensions de l' explorateur disponibles (comme TurtoiseSVN). A part cela, je suis d'accord avec Michael : Git n'est pas meilleur ou pire que Subversion, il est différent.

Créé 18/09/2008 à 19:44
source utilisateur

voix
8

David Richards WANdisco Blog sur Subversion / GIT

L'émergence de GIT a apporté avec elle une race de fondamentalistes DVCS - la « Gitterons » - qui pensent autre chose que GIT est de la merde. Les Gitterons semblent penser génie logiciel qui se passe sur leur propre île et oublient souvent que la plupart des organisations n'emploient pas les ingénieurs logiciels exclusivement supérieurs. C'est ok mais pas comment 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 dans la région de cinq millions d'utilisateurs et environ la moitié des l'ensemble du marché.

Le problème que nous avons vu était que les Gitterons faisaient feu (bon marché) coups de feu à Subversion. Tweets comme « Subversion est si [lent / merdiques / restrictive / ne sent pas bon / me regarde de façon amusante] et maintenant je GIT et [tout fonctionne dans ma vie / ma femme est tombée enceinte / je suis une petite amie après 30 ans d'essai / I a gagné six fois en cours d'exécution sur la table de blackjack]. Vous obtenez l'image.

Créé 17/09/2010 à 19:22
source utilisateur

voix
8

L' une des choses sur SubVersion qui me contrarie est qu'il met son propre dossier dans chaque répertoire d'un projet, alors que git met seul dans le répertoire racine. Ce n'est pas que grand d'une affaire, mais de petites choses comme ça additionnent.

Bien sûr, SubVersion a tortue, qui est [généralement] très agréable.

Créé 22/08/2008 à 16:24
source utilisateur

voix
7

Git fait également ramification et la fusion vraiment facile. Subversion 1.5 vient d'ajouter le suivi de fusion, mais Git est encore mieux. Avec branchement Git est très rapide et pas cher. Il permet de créer une branche pour chaque nouvelle fonctionnalité plus réalisable. Oh, et les dépôts Git sont très efficaces avec un espace de stockage par rapport à Subversion.

Créé 09/08/2008 à 04:22
source utilisateur

voix
6

Facile Git a une belle page comparant l' utilisation réelle de Git et SVN qui vous donnera une idée de ce que les choses Git peuvent faire (ou faire plus facilement) par rapport à SVN. (Techniquement, cela est basé sur Git facile, qui est un emballage léger au - dessus de Git.)

Créé 22/08/2008 à 16:19
source utilisateur

voix
6

Il est tout au sujet de la facilité d'utilisation / étapes nécessaires pour faire quelque chose.

Si je développe un 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 garder en tapant dans le référentiel d'URL lorsque vous faites se confond.

Si elle était seulement 2 personnes, je dirais que git est aussi plus facile, parce que vous pouvez juste pousser et tirer de eachother.

Une fois que vous obtenez au-delà si, je vais pour la subversion, parce qu'à ce moment-là, vous devez configurer un serveur « dédié » ou l'emplacement.

Vous pouvez le faire tout aussi bien avec git comme avec SVN, mais les avantages de git obtenir compensés par la nécessité de faire des mesures supplémentaires pour synchroniser avec un serveur central. Dans SVN vous vous engagez juste. Dans git vous devez git commit, puis git pousser. L'étape supplémentaire devient gênant tout simplement parce que vous finissez par faire tellement.

SVN a aussi l'avantage de meilleurs outils de l'interface graphique, mais l'écosystème git semble rattraper rapidement, donc je ne vous inquiétez pas à ce sujet à long terme.

Créé 04/08/2008 à 00:38
source utilisateur

voix
5

J'aime Git car il aide réellement développeur de communication au développeur sur un support à 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 éco-système qui aide à gérer un grand bassin de développeurs travaillant sur un seul projet.

Par exemple dire que vous faites confiance aux développeurs 5 et seulement tirer les codes de leur dépôt. Chacun de ces développeurs a son propre réseau de confiance d'où ils tirent des codes. Ainsi, le développement est basé sur ce tissu de confiance des développeurs où la responsabilité de code est partagé entre la communauté du développement.

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

Créé 05/10/2008 à 17:52
source utilisateur

voix
5

Git et DVCS en général est grande pour les développeurs qui font 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 engager à sa mise en pension, puis elle local doit pousser ce changeset à vous ou vous devez tirer d'elle.

Mon propre raisonnement me fait pense aussi DVCS rend 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 le faire push / pull à partir du dépôt de tout le monde, de résoudre les conflits qui auraient été résolus au commit initial avant, puis en faisant la construction, et ayant tous les autres développeurs resynchroniser leurs prises en pension.

Tout cela peut être résolu avec les processus humains, bien sûr; DVCS vient de se casser quelque chose qui a été fixé par un contrôle centralisé de version afin de fournir de nouvelles commodités.

Créé 04/08/2008 à 00:08
source utilisateur

voix
4

Je pense que Subversion est très bien .. jusqu'à ce que vous commencez à fusionner .. ou faire quoi que ce soit compliqué .. ou faire quelque chose Subversion pense est compliqué (comme faire des requêtes pour savoir quelles branches sali avec un fichier particulier, où un changement réellement vient, la détection de copie et de pâtes , etc)...

Je suis en désaccord avec la réponse gagnante, disant que le principal avantage de GIT est un travail hors ligne - il est certainement utile, mais il est plus comme un supplément pour mon cas d'utilisation. SVK peut travailler hors ligne aussi, encore il n'y a pas de doute pour moi que l' on à investir mon temps d'apprentissage).

Il est juste qu'il est incroyablement puissant et rapide et, bien -après se habituer aux concepts - très utiles (oui, en ce sens: facile à utiliser).

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

Créé 27/07/2010 à 16:40
source utilisateur

voix
4

Quelques réponses ont fait allusion à ces derniers, mais je veux faire 2 points explicites:

1) La capacité à faire commits sélectifs (par exemple git add --patch). Si votre répertoire de travail contient plusieurs modifications qui ne font pas partie du même changement logique, Git rend très facile de faire une livraison qui comprend seulement une partie des changements. Avec Subversion, il est difficile.

2) La capacité de commettre sans le public du changement. Dans Subversion, tout est immédiatement commettras publique, et donc irrévocable. Cela limite considérablement la capacité du développeur à « engager très tôt, souvent commettre ».

Git est plus qu'un simple VCS; il est aussi un outil de développement des correctifs. Subversion est simplement un VCS.

Créé 07/08/2009 à 15:59
source utilisateur

voix
3

Ceci est la mauvaise question à poser. Il est trop facile de se concentrer sur les verrues git et de formuler un argument au sujet de pourquoi la subversion est ostensiblement mieux, au moins pour certains cas d'utilisation. Le fait que git a été conçu comme un jeu de construction contrôle de version à faible niveau et possède une interface orientée développeur linux baroque rend plus facile pour les guerres saintes pour gagner la traction et la légitimité perçue. les partisans git cognent le tambour avec des millions d'avantages de flux de travail, qui svn les gars proclament inutiles. Très vite, le débat est encadrée comme centralisée vs distribué, qui sert les intérêts de la communauté outil svn entreprise. Ces entreprises, qui sont généralement mis sur les articles les plus convaincants sur la supériorité de la subversion dans l'entreprise,

Mais voici le problème: Subversion est un impasse architecturale .

Alors que vous pouvez prendre git et construire un remplacement de la subversion centralisée assez facilement, en dépit d'être autour de plus de deux fois plus longtemps svn n'a jamais été en mesure de faire fonctionner partout fusion-même le suivi de base près aussi bien qu'il le fait dans git. Une raison fondamentale est la décision de conception de faire les mêmes branches que les répertoires. Je ne sais pas pourquoi ils sont allés à l'origine de cette façon, il est certainement très simple partielle checkouts. Malheureusement, il est également impossible de suivre l'histoire correctement. Maintenant, vous êtes évidemment censé utiliser les conventions de mise en page de dépôt de subversion pour séparer les branches de répertoires réguliers, et svn utilise des heuristiques pour faire fonctionner les choses pour les cas d'utilisation quotidienne. Mais tout cela est juste tapisser sur une très mauvaise et en limitant la décision de conception de bas niveau. Etre capable d'un faire une diff garde-sage (plutôt que diff répertoire sage) est une fonctionnalité de base et critique pour un système de contrôle de version, et simplifie considérablement le fonctionnement interne, permettant de construire des fonctionnalités plus intelligentes et utiles sur le dessus de celui-ci. Vous pouvez voir la quantité d'effort qui a été mis en subversion extension, et encore à quel point il est derrière de la culture actuelle des VCSes modernes en termes d'opérations fondamentales telles que la résolution de fusion.

Maintenant, voici mon coeur-feutre et des conseils agnostique pour toute personne qui croit encore Subversion est assez bon pour l'avenir:

Subversion ne rattrapera jamais les nouvelles races de VCSes qui ont appris des erreurs du RCS et CVS; il est une impossibilité technique à moins qu'ils rééquiper le modèle de référentiel à partir du haut du sol, mais il ne serait pas vraiment svn serait-il? Peu importe combien vous pensez que vous ne pas les capacités d'un VCS moderne, votre ignorance ne vous protéger contre les pièges de la subversion, dont beaucoup sont des situations impossibles ou difficiles à résoudre dans d'autres systèmes.

Il est extrêmement rare que l'infériorité technique d'une solution est ainsi parce qu'il est clair coupé avec svn, certainement je ne déclare une telle opinion sur win-vs-linux ou emacs-vs-vi, mais dans ce cas, il est donc le contrôle clearcut, et la source est un outil fondamental dans l'arsenal du développeur, que je pense qu'il faut dire sans équivoque. Quelle que soit l'obligation d'utiliser svn pour des raisons d'organisation, je conjure tous les utilisateurs svn de ne pas laisser leur esprit logique, une fausse croyance que 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 un programmeur plus efficace si vous apprenez comment utiliser VCSes mieux conçus, que ce soit Git, Mercurial, Darcs, ou bien d'autres.

Créé 29/05/2011 à 18:30
source utilisateur

voix
3

J'adore être en mesure de gérer les branches locales de mon code source Git sans l'eau brouillant du dépôt central. Dans de nombreux cas, je vais extrais par checkout le code du serveur Subversion et exécuter un dépôt Git local juste pour être en mesure de le faire. Il est également grand que l'initialisation d'un dépôt Git ne pollue pas le système de fichiers avec un tas de dossiers .svn ennuyeux partout.

Et aussi loin que le support d'outils de Windows, TortoiseGit gère les bases très bien, mais je préfère encore la ligne de commande à moins que je veux afficher le journal. Je aime vraiment la façon Tortoise {Git | SVN} aide à la lecture de commettre des journaux.

Créé 10/02/2010 à 23:54
source utilisateur

voix
3

Merci au fait qu'il n'a pas besoin de communiquer avec un serveur central en permanence, à peu près chaque commande est exécutée en moins d'une seconde (évidemment git push / pull / fetch sont plus lents simplement parce qu'ils doivent initalise connexions SSH). Branching est beaucoup plus facile (une simple commande à la branche, une simple commande de fusionner)

Créé 30/08/2008 à 13:01
source utilisateur

voix
2

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

Créé 09/03/2011 à 15:05
source utilisateur

voix
2

Eric Sink de SourceGear a écrit série d'articles sur les différences entre les contrôles de version distribués et les systèmes non distribuée. Il compare les avantages et les inconvénients de la plupart des systèmes de contrôle de version populaire. Lecture très intéressante.
Les articles peuvent être trouvés sur son blog, www.ericsink.com :

Créé 13/10/2009 à 14:36
source utilisateur

voix
2

Subversion est très facile à utiliser. Je ne l'ai jamais trouvé dans les dernières années un problème ou que quelque chose ne fonctionne pas comme prévu. Aussi il y a beaucoup d'excellents outils de l'interface graphique et le soutien à l'intégration SVN est grande.

Avec Git vous obtenez un VCS plus souple. Vous pouvez l'utiliser de la même manière comme SVN avec un répertoire distant sur lequel vous vous engagez toutes les modifications. Mais vous pouvez aussi l'utiliser hors ligne et la plupart du temps que pousser les changements de temps en temps pour 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 mauvaises, créant des branches ou indirectement des messages d'erreur avec des informations pas beaucoup sur l'erreur et où je dois chercher 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 crochet très flexible pour fusionner propres scripts et ainsi vous obtenez toutes les choses dont vous avez besoin et plus, mais il a besoin de plus de temps et la lecture de la documentation ;)

Si vous travaillez la plupart du temps en mode hors connexion avec votre référentiel local vous n'avez pas de sauvegarde si quelque chose est perdu sur votre machine locale. Avec SVN vous travaillez surtout avec un dépôt distant qui est en même temps votre sauvegarde sur un autre serveur ... Git peut fonctionner de la même manière, mais ce ne fut pas le but principal de Linus 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-Git mieux alors SVN? Les développeurs qui n'a besoin que d'une histoire de version et un mécanisme de sauvegarde ont une vie bonne et facile avec SVN. Les développeurs qui travaillent souvent avec des branches, des tests plus des versions en même temps ou de travail peuvent la plupart du temps hors ligne bénéficier des fonctionnalités de Git. Il y a quelques fonctionnalités très utiles comme Stashing pas trouvé avec SVN qui peut rendre la vie plus facile. Mais de l'autre côté tous les gens auront besoin de toutes les fonctionnalités. Donc, je ne vois pas les morts de SVN.

Git a besoin d' une meilleure documentation et les rapports d'erreur doit être plus utile. De plus , les interfaces graphiques utiles existantes ne sont que rarement. Cette fois , je n'ai trouvé 1 GUI pour Linux avec prise en charge de la plupart des fonctionnalités de Git (git-cola). Intégration Eclipse travaille mais son pas officiel publié et il n'y a pas de site de mise à jour officielle (seulement une partie du site de mise à jour externe périodique construit à partir du tronc http://www.jgit.org/updates ) Donc Git ce jour la manière la plus préférée à utiliser est la ligne de commande.

Créé 13/10/2009 à 14:14
source utilisateur

voix
1

Pourquoi je pense que Subversion est meilleur que Git (au moins pour les projets sur lesquels je travaille), principalement en raison de sa facilité d'utilisation, et flux de travail plus simple:

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

Créé 22/10/2010 à 17:25
source utilisateur

voix
1

Je suis d' habitation dans la terre Git ces derniers temps, et je l' aime pour des projets personnels, mais je ne serais pas en mesure de passer des projets de travail pour encore de Subversion étant donné le changement dans la pensée du besoin du personnel, sans aucun des avantages pressants. De plus , le plus grand projet que nous courons en interne est extrêmement dépendante de svn: externals qui, de ce que j'ai vu jusqu'à présent, ne fonctionne pas si bien et en toute transparence dans Git.

Créé 25/04/2010 à 22:35
source utilisateur

voix
1

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 Vs. SVN l'argument Git a fait rage depuis un certain temps, avec tout le monde ayant leur propre opinion sur ce qui est mieux. Cela a même été élevé dans la des questions lors de notre webinaire sur Subversion en 2010 et au-delà.

Hyrum Wright, notre directeur de l'Open Source et le président de la Société Subversion parle des différences entre Subversion et Git, ainsi que d'autres systèmes de contrôle version distribuée (DVCS).

Il parle aussi des changements à venir dans Subversion, comme copie de travail de nouvelle génération (WC-NG), qui, selon lui causer un certain nombre d'utilisateurs Git pour reconvertir Subversion.

Avoir une montre de sa vidéo et laissez-nous savoir ce que vous pensez soit de commenter sur ce blog ou en affichant dans nos forums. L'inscription est simple et ne vous prendra que quelques instants!

Créé 10/02/2010 à 19:51
source utilisateur

voix
1

Git dans Windows est très bien maintenant pris en charge.

Consultez GitExtensions = http://code.google.com/p/gitextensions/

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

Créé 10/02/2010 à 17:29
source utilisateur

voix
1

Tout d'abord, le contrôle simultané de la version semble un problème facile à résoudre. Ce n'est pas du tout. En tous cas...

SVN est tout à fait non-intuitive. Git est encore pire. [Spéculation sarcastique] Cela pourrait être parce que les développeurs, que comme des problèmes difficiles tels que le contrôle simultané de version, n'ont pas beaucoup d'intérêt à faire une bonne interface utilisateur. [/ Sarcastique spéculation]

Partisans SVN pensent qu'ils ne ont pas besoin d' un système de contrôle de version distribué. Je pensais aussi. Mais maintenant que nous utilisons exclusivement Git, je suis un croyant. Maintenant fonctionne le contrôle de version pour moi et l'équipe / projet au lieu de simplement travailler pour le projet. Quand je besoin d' une branche, je branche. Parfois , il est une branche qui a une branche correspondante sur le serveur, et parfois il ne fonctionne pas. Sans parler de tous les autres avantages que je vais devoir aller étudier sur (en partie grâce à l'absence Arcane et absurde de l' interface utilisateur qui est un système de contrôle de version moderne).

Créé 03/01/2010 à 13:45
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more