J'ai utilisé Subversion pendant quelques années et après avoir utilisé SourceSafe J'aime 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 race 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 il n'est pas non plus pire. C'est différent.
La différence essentielle 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 voulez avoir le contrôle de la source pour pouvoir revenir 3 heures en arrière.
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 en ce moment), vous ne pouvez pas commiter. 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 y commiter et bénéficier de tous les avantages du contrôle de source. Lorsque vous retrouvez la connectivité au dépôt principal, vous pouvez commiter sur celui-ci.
Cela semble bien au premier abord, 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 après tout), mais j'ai l'impression que beaucoup de gens sautent dans le train du "contrôle de source distribué" juste parce que c'est nouveau et que c'est écrit par Linus Torvalds, sans vraiment savoir pourquoi/si c'est mieux.
Subversion a des problèmes, mais Git, Mercurial, CVS, TFS ou autre en ont aussi.
Edit : Cette réponse a maintenant un an et génère toujours de nombreux votes positifs, alors j'ai pensé ajouter quelques explications supplémentaires. Au cours de l'année écoulée depuis que j'ai écrit cette réponse, Git a gagné beaucoup de terrain et de soutien, en particulier depuis que des sites comme GitHub ont vraiment décollé. J'utilise à la fois Git et Subversion aujourd'hui et j'aimerais partager quelques informations personnelles.
Tout d'abord, Git peut être vraiment déroutant au début quand on travaille de manière décentralisée. Qu'est-ce qu'un dépôt distant ? et Comment configurer correctement le dépôt initial ? sont deux questions qui se posent au début, surtout en comparaison avec le simple "svnadmin create" de SVN, le "git init" de Git peut prendre les paramètres --bare et --shared qui semblent être la "bonne" façon de configurer un dépôt centralisé. Il y a des raisons pour cela, mais cela ajoute de la complexité. La documentation de la commande "checkout" est très confuse pour les personnes qui changent de méthode - la "bonne" méthode semble être "git clone", alors 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 dépôt (Oui, je connais SVK ou les moyens de copier le dépôt). Avec Git, c'est le mode par défaut de toute façon. C'est une commande supplémentaire cependant (git commit commet localement, alors que git push origin master pousse la branche master vers la branche distante nommée "origin").
Comme dit plus haut : Git ajoute de la complexité. Deux modes de création de dépôts, 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 encore un "master-repository" central).
En outre, l'outillage est encore insuffisant, du moins sous Windows. Oui, il existe un AddIn Visual Studio, mais j'utilise toujours git bash avec msysgit.
SVN a l'avantage d'être BEAUCOUP plus simple à apprendre : Il y a votre dépôt, toutes les modifications à y apporter, si vous savez comment créer, commiter et vérifier et vous êtes prêt à partir et vous pouvez récupérer des choses comme les branches, les mises à jour etc. plus tard.
Git a l'avantage d'être BEAUCOUP mieux adapté si certains développeurs ne sont pas toujours connectés au dépôt maître. De plus, il est beaucoup plus rapide que SVN. Et d'après ce que j'ai entendu, la prise en charge des branches et de la fusion est bien meilleure (ce qui est normal, puisque ce sont les raisons principales pour lesquelles il a été écrit).
Cela explique également pourquoi il fait tant parler de lui sur Internet, car Git est parfaitement adapté aux projets Open Source : Il suffit de le bifurquer, de livrer vos modifications dans votre propre bifurcation, puis de demander au responsable du projet original de reprendre vos modifications. Avec Git, cela fonctionne tout simplement. Vraiment, essayez-le sur Github, c'est magique.
Je vois aussi des passerelles Git-SVN : Le dépôt central est un dépôt Subversion, mais les développeurs travaillent localement avec Git et la passerelle pousse ensuite leurs modifications vers SVN.
Mais même avec ce long ajout, je reste fidèle à mon message principal : Git n'est pas meilleur ou pire, il est juste différent. Si vous avez besoin d'un "contrôle de source hors ligne" et que vous êtes prêt à passer un peu plus de temps à l'apprendre, c'est fantastique. Mais si vous avez un contrôle de source strictement centralisé et/ou si 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 les excellents outils (au moins sous Windows) de SVN brillent.
Avec Git, vous pouvez pratiquement tout faire hors ligne, car tout le monde a son propre référentiel.
Il est très facile de créer des branches et de fusionner entre elles.
Même si vous n'avez pas les droits de commit pour un projet, vous pouvez toujours avoir votre propre dépôt en ligne, et publier des "demandes de push" pour vos correctifs. Tous ceux qui aiment vos correctifs peuvent les intégrer à leur projet, y compris les mainteneurs officiels.
Il est trivial de bifurquer un projet, de le modifier et de continuer à intégrer les corrections de bogues de la branche HEAD.
Git fonctionne pour les développeurs du noyau Linux. Cela signifie qu'il est très rapide (il doit l'être) et qu'il peut être utilisé par 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 le flux de travail que vous voulez, et Git le supportera.
Enfin, il y a GitHub un excellent site pour héberger vos dépôts Git.
Inconvénients de Git :
D'autres réponses ont fait un bon travail d'explication des fonctionnalités de base de Git (qui sont excellentes). Mais il y a aussi tellement de petit pour que Git se comporte mieux et m'aide à garder ma vie plus saine. Voici quelques-unes de ces petites choses :
" Pourquoi Git est meilleur que X "Ce document présente les avantages et les inconvénients de Git par rapport aux autres SCM.
En bref :
Il y a quelques inconvénients :
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 pushLà où Git brille vraiment, c'est lorsqu'il s'agit 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
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
