Pourquoi Git est-il meilleur que Subversion?

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

Pourtant, un nombre croissant de développeurs affirment 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és, tels que Git .

Comment Git améliore-t-il Subversion?

Git n'est pas meilleur que Subversion. Mais ce n'est pas pire non plus. C'est différent.

La principale différence est qu'il est décentralisé. Imaginez que vous êtes un développeur sur la route, que vous développez sur votre ordinateur portable et que vous souhaitez avoir le contrôle des sources afin de pouvoir reculer de 3 heures.

Avec Subversion, vous avez un problème: le référentiel SVN peut être dans un endroit que vous ne pouvez pas atteindre (dans votre entreprise, et vous n'avez pas Internet pour le moment), vous ne pouvez pas vous engager. Si vous voulez faire une copie de votre code, vous devez littéralement le copier / coller.

Avec Git, vous n'avez pas ce problème. Votre copie locale est un référentiel et vous pouvez vous y engager et bénéficier de tous les avantages du contrôle de code source. Lorsque vous récupérez la connectivité au référentiel principal, vous pouvez vous engager contre.

Cela semble bon au début, mais gardez à l'esprit la complexité supplémentaire de cette approche.

Git semble être la chose "nouvelle, brillante et cool". Ce n'est en aucun cas mauvais (il y a une raison pour laquelle Linus l'a écrit pour le développement du noyau Linux), mais je pense que beaucoup de gens sautent dans le train "Distributed Source Control" juste parce qu'il est nouveau et écrit par Linus Torvalds, sans réellement savoir pourquoi / si c'est mieux.

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

Éditer: Donc, cette réponse a maintenant un an et génère toujours beaucoup de votes positifs, alors j'ai pensé ajouter quelques explications. Au cours de la dernière année depuis la rédaction de cet article, Git a gagné beaucoup d'élan et de soutien, en particulier depuis que des sites comme GitHub ont vraiment décollé. J'utilise à la fois Git et Subversion de nos jours et j'aimerais partager quelques idées personnelles.

Tout d'abord, Git peut être très déroutant au début lorsqu'il travaille de manière décentralisée. Qu'est-ce qu'une télécommande? et Comment configurer correctement le référentiel initial? sont deux questions qui se posent au début, en particulier par rapport au simple "svnadmin create" de SVN, "git init" de Git peut prendre les paramètres --bare et --shared qui semble être la "bonne" façon de mettre en place un système centralisé dépôt. Il y a des raisons à cela, mais cela ajoute de la complexité. La documentation de la commande "checkout" est très déroutante pour les personnes qui changent - la manière "correcte" semble être "git clone", tandis que "git checkout" semble changer de branche.

Git brille VRAIMENT lorsque vous êtes décentralisé. J'ai un serveur à la maison et un ordinateur portable sur la route, et SVN ne fonctionne tout simplement pas bien ici. Avec SVN, je ne peux pas avoir de contrôle de source local si je ne suis pas connecté au référentiel (Oui, je connais SVK ou les moyens de copier le dépôt). Avec Git, c'est de toute façon le mode par défaut. C'est une commande supplémentaire (git commit s'engage localement, alors que git push origin master pousse la branche master vers la télécommande nommée "origin").

Comme dit ci-dessus: Git ajoute de la complexité. Deux modes de création de référentiels, checkout vs clone, commit vs push ... Vous devez savoir quelles commandes fonctionnent localement et lesquelles fonctionnent avec "le serveur" (je suppose que la plupart des gens aiment toujours un "master-repository" central ).

De plus, l'outillage est encore insuffisant, au moins sous Windows. Oui, il existe un complément Visual Studio, mais j'utilise toujours git bash avec msysgit.

SVN a l'avantage qu'il est BEAUCOUP plus simple à apprendre: il y a votre référentiel, toutes les modifications apportées à celui-ci, si vous savez comment créer, valider et extraire et que vous êtes prêt à partir et pouvez ramasser des choses comme la ramification, la mise à jour, etc. plus tard sur.

Git a l'avantage qu'il est BEAUCOUP mieux adapté si certains développeurs ne sont pas toujours connectés au référentiel maître. De plus, c'est beaucoup plus rapide que SVN. Et d'après ce que j'entends, le support de branchement et de fusion est beaucoup mieux (ce qui est normal, car ce sont les principales raisons pour lesquelles il a été écrit).

Cela explique également pourquoi il gagne autant de buzz sur Internet, car Git est parfaitement adapté aux projets Open Source: il suffit de le fork, de valider vos modifications dans votre propre Fork, puis de demander au responsable du projet d'origine de retirer vos modifications. Avec Git, cela fonctionne. Vraiment, essayez-le sur Github, c'est magique.

Ce que je vois aussi, ce sont des ponts Git-SVN: le référentiel central est un dépôt Subversion, mais les développeurs travaillent localement avec Git et le pont pousse ensuite leurs modifications vers SVN.

Mais même avec ce long ajout, je reste fidèle à mon message principal: Git n'est ni meilleur ni pire, c'est juste différent. Si vous avez besoin de "Contrôle de source hors ligne" et la volonté de passer un peu plus de temps à l'apprendre, c'est fantastique. Mais si vous avez un contrôle de source strictement centralisé et / ou que vous avez du mal à introduire le contrôle de source en premier lieu parce que vos collègues ne sont pas intéressés, alors la simplicité et l'excellent outillage (au moins sur Windows) de SVN brillent.

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

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

Même si vous ne disposez pas de droits de validation pour un projet, vous pouvez toujours avoir votre propre référentiel en ligne et publier des «demandes push» pour vos correctifs. Tous ceux qui aiment vos patchs peuvent les intégrer à leur projet, y compris les responsables officiels.

Il est trivial de bifurquer un projet, de le modifier et de continuer à fusionner les corrections de bogues de la branche HEAD.

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

Git est très flexible, très TIMTOWTDI (il y a plus d'une façon de le faire). Vous pouvez utiliser le workflow de votre choix et Git le prendra en charge.

Enfin, il y a GitHub , un excellent site pour héberger vos référentiels Git.

Inconvénients de Git:

• c'est beaucoup plus difficile à apprendre, car 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 interface graphique (comme le grand TortoiseSVN )

D'autres réponses ont bien expliqué les principales fonctionnalités de Git (qui sont excellentes). Mais il y a aussi tellement de petits moyens pour que Git se comporte mieux et aide à garder ma vie plus saine d'esprit. 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 videra des fichiers supplémentaires sur votre disque.
2. Git a la commande 'bisect'. C'est bien.
3. SVN crée des répertoires .svn dans chaque dossier (Git ne crée qu'un seul répertoire .git). Chaque script que vous écrivez, et chaque grep que vous faites, devront être écrits pour ignorer ces répertoires .svn. Vous avez également besoin d'une commande entière ("exportation svn") juste pour obtenir une copie saine de vos fichiers.
4. Dans SVN, chaque fichier et dossier peut provenir d'une révision ou d'une branche différente. Au début, cela semble agréable d'avoir cette liberté. Mais ce que cela signifie en réalité, c'est qu'il existe un million de façons différentes de visser complètement votre caisse locale. (par exemple, si "svn switch" échoue à mi-chemin, ou si vous entrez une commande incorrecte). Et le pire est: si jamais vous vous retrouvez dans une situation où certains de vos fichiers proviennent d'un endroit, et certains d'un autre, le "statut svn" vous dira que tout est normal. Vous devrez faire "svn info" sur chaque fichier / répertoire pour découvrir à quel point les choses sont étranges. Si "git status" vous dit que les choses sont normales, alors vous pouvez avoir confiance que les choses sont vraiment normales.
5. Vous devez avertir SVN chaque fois que vous déplacez ou supprimez quelque chose. Git va juste le découvrir.
6. Ignorer la sémantique est plus facile dans Git. Si vous ignorez un modèle (tel que * .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 ait pas de 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 des paramètres d'ignorance "privés" (en utilisant le fichier .git / info / exclude), qui n'affecteront personne d'autre.

" Pourquoi Git est meilleur que X " décrit les différents avantages et inconvénients de Git par rapport aux autres SCM.

Brièvement:

• Git suit le 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. À mon avis, il est beaucoup plus facile de développer simultanément et en collaboration qu'avec Subversion. Il rend également possible le développement hors ligne .
• Il n'impose aucun flux de travail , comme on le voit sur le site Web lié ci-dessus , il existe de nombreux flux de travail possibles avec Git. Un flux de travail de style Subversion est facilement imité.
• Les référentiels Git sont beaucoup plus petits en taille de fichier que les référentiels Subversion. Il n'y a qu'un seul répertoire ".git", par opposition à des dizaines de référentiels ".svn" (notez que Subversion 1.7 et plus utilise désormais un seul répertoire comme Git.)
• La mise en scène espace est impressionnant, il vous permet de voir les changements que vous commettrez, valider les modifications partielles et faire diverses autres choses.
• Le stashing est inestimable lorsque vous effectuez un développement "chaotique" ou que vous souhaitez simplement corriger un bug pendant que vous travaillez sur autre chose (sur une branche différente).
• Vous pouvez réécrire l'historique , ce qui est idéal pour préparer des ensembles de correctifs et corriger vos erreurs ( avant de publier les validations)
• … Et bien plus encore.

Il y a quelques inconvénients:

• Il n'y a pas encore beaucoup de bonnes interfaces graphiques. C'est nouveau et Subversion existe depuis bien plus longtemps, donc c'est naturel car il y a quelques interfaces en développement. Certains bons incluent TortoiseGit et GitHub pour Mac .
• Les extractions / clones partiels de référentiels ne sont pas possibles pour le moment (j'ai lu que c'est en développement). Cependant, il existe un support de sous-module. Git 1.7+ prend en charge les extractions clairsemées .
• Cela pourrait être plus difficile à apprendre, même si je n'ai pas trouvé que c'était le cas (il y a environ un an). Git a récemment amélioré son interface et est assez convivial.

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 [email protected]:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Là où Git brille vraiment, c'est de créer des branches et de travailler avec d'autres personnes.

Google Tech Talk: Linus Torvalds sur git

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

La page de comparaison du Git Wiki

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

Eh bien, c'est distribué. Les repères indiquent qu'il est considérablement plus rapide (compte tenu de sa nature distribuée, les opérations telles que les différences et les journaux sont toutes locales, ce qui est bien sûr incroyablement plus rapide dans ce cas), et les dossiers de travail sont plus petits (ce qui me souffle encore).

Lorsque vous travaillez sur 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 extrayant les révisions. Cela représente un instantané dans le temps de ce à quoi ressemble le référentiel. Vous mettez à jour votre copie de travail via des mises à jour et vous mettez à jour le référentiel via des validations.

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

On pourrait penser que Git prendrait beaucoup d'espace sur votre disque dur, mais d'après quelques repères que j'ai vus, cela prend en fait moins. Ne me demandez pas comment. Je veux dire, il a été construit par Linus, il connaît une chose ou deux sur les systèmes de fichiers, je suppose.

Les principaux points que j'aime à propos du DVCS sont les suivants:

1. Vous pouvez commettre des choses cassées. Cela n'a pas d'importance car les autres peuples ne les verront pas tant que vous ne les publierez pas. Le temps de publication est différent du temps de validation.
2. Pour cette raison, vous pouvez vous engager plus souvent.
3. Vous pouvez fusionner une fonctionnalité complète. Cette fonctionnalité aura sa propre branche. Tous les commits de cette branche seront liés à cette fonctionnalité. Vous pouvez le faire avec un CVCS mais avec DVCS c'est la valeur par défaut.
4. Vous pouvez rechercher votre historique (trouver quand une fonction a changé)
5. Vous pouvez annuler un pull si quelqu'un bousille le référentiel principal, vous n'avez pas besoin de corriger les erreurs. Effacez simplement la fusion.
6. Lorsque vous avez besoin d'un contrôle de source dans n'importe quel répertoire, faites: git init. et vous pouvez valider, annuler les modifications, etc ...
7. C'est rapide (même sous 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 de beaux bonus.

Le plus drôle, c'est que j'héberge des projets dans Subversion Repos, mais que j'y accède via la commande Git Clone.

Veuillez lire Développer avec Git sur un projet Google Code

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.

L'utilisation de Git sur un référentiel Svn me donne des avantages:

1. Je peux travailler distribué sur plusieurs machines, en validant et en tirant depuis et vers elles
2. J'ai un dépôt central backup/public svn pour que les autres puissent le vérifier
3. Et ils sont libres d'utiliser Git pour leur propre compte

Toutes les réponses ici sont comme prévu, centrées sur le programmeur, mais que se passe-t-il si votre entreprise utilise le contrôle des révisions en dehors du code source? Il existe de nombreux documents qui ne sont pas du code source et qui bénéficient du contrôle de version, et devraient vivre à proximité du code et non dans un autre CMS. La plupart des programmeurs ne travaillent pas isolément - nous travaillons pour des entreprises en tant que membres d'une équipe.

Dans cet esprit, comparez la facilité d'utilisation, à la fois dans l'outillage client et la formation, entre Subversion et git. Je ne vois pas de scénario où un système de contrôle de révision distribué sera plus facile à utiliser ou à expliquer à un non-programmeur. J'adorerais me tromper, car alors je serais en mesure d'évaluer git et j'espère réellement qu'il sera accepté par les personnes qui ont besoin d'un contrôle de version qui ne sont pas des programmeurs.

Même alors, si la direction nous demandait pourquoi nous devrions passer d'un système de contrôle de révision centralisé à un système de contrôle des révisions distribué, je serais bien en peine de donner une réponse honnête, car nous n'en avons pas besoin.

Avertissement: je me suis intéressé à Subversion dès le début (vers la version 0.29), donc je suis évidemment partial, mais les entreprises pour lesquelles j'ai travaillé depuis lors bénéficient de mon enthousiasme car j'ai encouragé et soutenu son utilisation. Je soupçonne que c'est ainsi que cela se passe avec la plupart des éditeurs de logiciels. Avec autant de programmeurs qui sautent dans le train git, je me demande combien d'entreprises vont manquer les avantages d'utiliser le contrôle de version en dehors du code source? Même si vous avez des systèmes distincts pour différentes équipes, vous passez à côté de certains avantages, tels que l'intégration (unifiée) du suivi des problèmes, tout en augmentant les exigences de maintenance, de matériel et de formation.

Subversion est toujours un système de contrôle de version beaucoup plus utilisé, ce qui signifie qu'il a un meilleur support d'outils. Vous trouverez des plugins SVN matures pour presque tous les IDE , et de bonnes extensions d'explorateur sont disponibles (comme TurtoiseSVN). A part ça, je devrai être d'accord avec Michael : Git n'est ni meilleur ni pire que Subversion, c'est différent.

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

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

Blog de David Richards WANdisco sur Subversion / GIT

L'émergence de GIT a amené avec lui une race de fondamentalistes DVCS - les «Gitterons» - qui pensent que tout autre que GIT est de la merde. Les Gitterons semblent penser que l'ingénierie logicielle se déroule sur leur propre île et oublient souvent que la plupart des organisations n'emploient pas exclusivement des ingénieurs logiciels seniors. Ce n'est pas grave, mais ce n'est pas ce que pense le reste du marché, et je suis heureux de le prouver: GIT, au dernier regard, avait moins de trois pour cent du marché alors que Subversion a environ cinq millions d'utilisateurs et environ la moitié des l'ensemble du marché.

Le problème que nous avons vu était que les Gitterons tiraient (à bas prix) sur Subversion. Des tweets comme «Subversion est tellement [lent / merdique / restrictif / ne sent pas bon / me regarde d'une manière amusante] 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'essais / J'ai gagné six fois en courant sur la table de blackjack]. Vous obtenez l'image.

Git facilite également les branchements et les fusions. Subversion 1.5 vient d'ajouter le suivi des fusions, mais Git est toujours meilleur. Avec Git, le branchement est très rapide et bon marché. Cela rend la création d'une branche pour chaque nouvelle fonctionnalité plus réalisable. Les référentiels Oh et Git sont très efficaces avec un espace de stockage par rapport à Subversion.

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

Si je développe un seul projet sur mon PC / ordinateur portable, git est meilleur, 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 de référentiel lorsque vous effectuez des fusions.

S'il n'y avait que 2 personnes, je dirais que git est aussi plus facile, car vous pouvez simplement pousser et tirer les uns des autres.

Une fois que vous avez dépassé cela, je choisirais Subversion, car à ce stade, 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é d'effectuer des étapes supplémentaires pour la synchronisation avec un serveur central. Dans SVN, vous vous engagez simplement. Dans git, vous devez git commit, puis git push. L'étape supplémentaire devient ennuyeuse simplement parce que vous finissez par le faire tellement.

SVN a également l'avantage de meilleurs outils GUI, mais l'écosystème git semble rattraper rapidement, donc je ne m'inquiéterais pas à ce sujet à long terme.

Easy Git a une belle page 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, cela est basé sur Easy Git, qui est un wrapper léger au-dessus de Git.)

Git et DVCS en général sont parfaits pour les développeurs qui font beaucoup de codage indépendamment les uns des autres, car chacun a sa propre branche. Si vous avez besoin d'un changement de la part de quelqu'un d'autre, elle doit s'engager dans son référentiel local, puis elle doit vous proposer ce jeu de modifications ou vous devez le lui retirer.

Mon propre raisonnement me fait également penser que DVCS rend les choses plus difficiles pour le contrôle 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 référentiel de tout le monde, de résoudre tous les conflits qui auraient été résolus au moment de la validation initiale, puis de faire la construction et de demander à tous les autres développeurs de resynchroniser leur repos.

Tout cela peut être résolu par 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 car il aide réellement le développeur de communication à développer au sein d'une équipe moyenne à grande. 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 écosystème de code source qui aide à gérer un large pool de développeurs travaillant sur un seul projet.

Par exemple, disons que vous faites confiance à 5 développeurs et que vous ne tirez que des codes de leur référentiel. Chacun de ces développeurs possède son propre réseau de confiance d'où il tire les codes. Ainsi, le développement est basé sur ce tissu de confiance des 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 y ont fait allusion, mais je veux expliciter 2 points:

1) La possibilité d'effectuer des commits sélectifs (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 facilite très facilement la validation qui n'inclut qu'une partie des modifications. Avec Subversion, c'est difficile.

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

Git est plus qu'un simple VCS; c'est aussi un outil pour développer des patchs. Subversion n'est qu'un VCS.

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 ne suis pas d'accord avec la réponse gagnante, affirmant que le principal avantage de GIT est le travail hors ligne - c'est certainement utile, mais cela ressemble plus à un supplément pour mon cas d'utilisation. SVK peut également fonctionner hors ligne, mais il ne fait aucun doute pour moi dans lequel investir mon temps d'apprentissage).

C'est juste qu'il est incroyablement puissant et rapide et, bien - après s'être habitué aux concepts - très utile (oui, dans ce sens: convivial).

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

Grâce au fait qu'il n'a pas besoin de communiquer avec un serveur central en permanence, presque toutes les commandes s'exécutent en moins d'une seconde (évidemment git push / pull / fetch sont plus lents simplement parce qu'ils doivent initaliser les connexions SSH). Le branchement est beaucoup plus facile (une commande simple pour créer une branche, une commande simple pour fusionner)

J'adore absolument pouvoir gérer les branches locales de mon code source dans Git sans embrouiller l'eau du référentiel central. Dans de nombreux cas, je vais extraire le code du serveur Subversion et exécuter un référentiel Git local juste pour pouvoir le faire. Il est également formidable que l'initialisation d'un référentiel Git ne pollue pas le système de fichiers avec un tas de dossiers .svn ennuyeux partout.

Et en ce qui concerne la prise en charge des outils Windows, TortoiseGit gère très bien les bases, mais je préfère toujours la ligne de commande, sauf si je veux afficher le journal. J'aime vraiment la façon dont Tortoise {Git | SVN} aide lors de la lecture des journaux de validation.

Ce n'est pas la bonne question à poser. Il est trop facile de se concentrer sur les verrues de git et de formuler un argument sur la raison pour laquelle la subversion est ostensiblement meilleure, au moins pour certains cas d'utilisation. Le fait que git ait été initialement conçu comme un ensemble de construction de contrôle de version de bas niveau et possède une interface baroque orientée développeur Linux facilite la traction et la légitimité perçue des guerres saintes. Les partisans de Git frappent le tambour avec des millions d'avantages de workflow, que les gars de svn proclament inutiles. Bientôt, l'ensemble du débat est défini comme centralisé vs distribué, ce qui sert les intérêts de la communauté des outils SVN d'entreprise. Ces entreprises, qui publient généralement les articles les plus convaincants sur la supériorité de subversion dans l'entreprise,

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

Alors que vous pouvez prendre git et créer un remplacement de subversion centralisé assez facilement, bien qu'il existe depuis plus de deux fois aussi longtemps, svn n'a jamais pu faire fonctionner le suivi de fusion, même de base, aussi proche que dans git. Une des raisons fondamentales de cela est la décision de conception de rendre les branches identiques aux répertoires. Je ne sais pas pourquoi ils sont allés de cette façon à l'origine, cela rend certainement les retraits partiels très simples. Malheureusement, il est également impossible de suivre correctement l'historique. Maintenant, évidemment, vous êtes censé utiliser les conventions de mise en page du référentiel subversion pour séparer les branches des répertoires ordinaires, et svn utilise des heuristiques pour faire fonctionner les choses pour les cas d'utilisation quotidiens. Mais tout cela se résume à une décision de conception de bas niveau très médiocre et limitante. Être capable de faire un diff au niveau du référentiel (plutôt qu'au niveau du répertoire) est une fonctionnalité de base et critique pour un système de contrôle de version, et simplifie considérablement les internes, permettant de créer des fonctionnalités plus intelligentes et utiles par-dessus. Vous pouvez voir dans la quantité d'efforts qui ont été déployés pour étendre la subversion, et pourtant à quel point elle est loin de la récolte actuelle de VCS modernes en termes d'opérations fondamentales comme la résolution de fusion.

Voici maintenant mes conseils sincères et agnostiques pour tous ceux qui croient encore que Subversion est assez bon pour l'avenir prévisible:

Subversion ne rattrapera jamais les nouvelles races de VCS qui ont appris des erreurs de RCS et CVS; c'est une impossibilité technique à moins qu'ils ne réorganisent le modèle de référentiel à partir de zéro, mais ce ne serait pas vraiment svn, n'est-ce pas? Peu importe à quel point vous pensez que vous ne disposez pas des capacités d'un VCS moderne, votre ignorance ne vous protégera pas des pièges de Subversion, dont beaucoup sont des situations qui sont impossibles ou facilement résolues dans d'autres systèmes.

Il est extrêmement rare que l'infériorité technique d'une solution soit aussi claire qu'elle l'est avec svn, je ne dirais certainement jamais une telle opinion sur win-vs-linux ou emacs-vs-vi, mais dans ce cas, il en est ainsi clearcut, 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 l'exigence 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 selon laquelle les VCS 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 programmeur, vous serez un programmeur plus efficace si vous apprenez à utiliser des VCS mieux conçus, que ce soit Git, Mercurial, Darcs ou bien d'autres.

Subversion est très facile à utiliser. Je n'ai jamais trouvé de problème ces dernières années ou que quelque chose ne fonctionne pas comme prévu. Il existe également de nombreux excellents outils GUI et la prise en charge de l'intégration SVN est importante.

Avec Git, vous obtenez un VCS plus flexible. Vous pouvez l'utiliser de la même manière que SVN avec un référentiel distant où vous validez toutes les modifications. Mais vous pouvez également l'utiliser principalement hors ligne et ne pousser que les modifications de temps en temps vers le référentiel distant. Mais Git est plus complexe et a une courbe d'apprentissage plus abrupte. Je me suis retrouvé pour la première fois à commettre de mauvaises branches, à créer des branches indirectement ou à recevoir 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 fonctionnent pas, mais GIT a un mécanisme de filtrage et de hook très flexible pour fusionner ses propres scripts et donc vous obtenez tout ce dont vous avez besoin et plus, mais il a besoin de plus de temps et de lecture de la documentation ;)

Si vous travaillez principalement hors ligne avec votre référentiel local, vous n'avez aucune sauvegarde si quelque chose est perdu sur votre machine locale. Avec SVN, vous travaillez principalement avec un référentiel distant qui est en même temps votre sauvegarde sur un autre serveur ... Git peut fonctionner de la même manière mais ce n'était pas l'objectif 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é.

Git est-il meilleur que SVN? Les développeurs qui n'ont besoin que d'un historique des versions et d'un mécanisme de sauvegarde ont une vie agréable et facile avec SVN. Les développeurs travaillant souvent avec des succursales, 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 stashing non trouvées avec SVN qui peuvent vous faciliter la vie. Mais d'un autre côté, tout le monde n'aura pas besoin de toutes les fonctionnalités. Je ne peux donc pas voir les morts de SVN.

Git a besoin d'une meilleure documentation et le rapport d'erreurs doit être plus utile. De plus, les interfaces graphiques utiles existantes ne le sont que rarement. Cette fois, je n'ai trouvé qu'une seule interface graphique pour Linux avec la prise en charge de la plupart des fonctionnalités de Git (git-cola). L'intégration Eclipse fonctionne mais sa sortie n'est pas officielle et il n'y a pas de site de mise à jour officiel (seulement un site de mise à jour externe avec des builds périodiques à partir du tronc http://www.jgit.org/updates ) Donc, la façon la plus préférée d'utiliser Git de nos 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 versions distribués et non distribués. Il compare les avantages et les inconvénients des systèmes de contrôle de version les plus populaires. Lecture très intéressante.
Des articles peuvent être trouvés sur son blog, www.ericsink.com :

• Lire les diffs

• Git est le C des outils de contrôle de version

• Sur le manque de respect de Git pour l'immuabilité et les meilleures pratiques pour un DVCS

• DVCS et DAG, partie 1

• DVCS et DAG, partie 2

• DVCS et suivi des bogues

• Historique de fusion, DAG et Darcs

• Pourquoi Git est-il si rapide?

• Mercurial, Subversion et Wesley Snipes

Pour les personnes à la recherche d'une bonne interface graphique Git, Syntevo SmartGit pourrait être une bonne solution. Son propriétaire, mais gratuit pour une utilisation non commerciale, fonctionne sur Windows / Mac / Linux et prend même en charge 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 Git fait rage depuis un certain temps maintenant, chacun ayant sa propre opinion sur ce qui est mieux. Cela a même été soulevé dans les questions lors de notre webinaire sur la subversion en 2010 et au-delà.

Hyrum Wright, notre directeur de l'Open Source et président de Subversion Corporation, parle 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 Working Copy Next Generation (WC-NG), qui, selon lui, entraîneront la reconversion d'un certain nombre d'utilisateurs de Git vers Subversion.

Regardez sa vidéo et dites-nous ce que vous en pensez en commentant ce blog ou en publiant sur nos forums. L'inscription est simple et ne prendra qu'un moment!

Git dans Windows est maintenant assez bien pris en charge.

Découvrez GitExtensions = http://code.google.com/p/gitextensions/

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

J'ai habité à Git land ces derniers temps, et je l'aime pour des projets personnels, mais je ne pourrais pas encore y transférer des projets de travail de Subversion compte tenu du changement de pensée des exigences du personnel, sans avantages pressants. De plus, le plus grand projet que nous exécutons en interne dépend extrêmement de svn: externals qui, d'après ce que j'ai vu jusqu'à présent, ne fonctionne pas aussi bien et de manière transparente dans Git.

Tout d'abord, le contrôle des versions simultanées semble être un problème facile à résoudre. Ce n'est pas du tout. En tous cas...

SVN est assez non intuitif. Git est encore pire. [sarcastic-speculation] Cela pourrait être dû au fait que les développeurs, comme les problèmes difficiles comme le contrôle de version simultané, n'ont pas beaucoup d'intérêt à faire une bonne interface utilisateur. [/ sarcastique-spéculation]

Les partisans de SVN pensent qu'ils n'ont pas besoin d'un système de contrôle de version distribué. J'ai pensé ça aussi. Mais maintenant que nous utilisons exclusivement Git, je suis un croyant. Maintenant, le contrôle de version fonctionne pour moi ET pour l'équipe / le 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 branche correspondante sur le serveur, et parfois non. Sans parler de tous les autres avantages que je vais devoir étudier (grâce en partie au manque d'arcane et absurde de l'interface utilisateur qui est un système de contrôle de version moderne).

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

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