Je travaille dans un département où personne n'a jamais utilisé le contrôle de code source auparavant, moi y compris.

J'essaie de pousser le concept. J'ai passé un peu de temps à rechercher SVN. J'ai appris quelques notions de base. Je peux créer / mettre à jour / extraire / valider avec la ligne de commande et depuis Tortoise. Je commence à apprendre à étiqueter et à brancher, mais je suis encore très confus à propos des conflits entre les branches et le tronc, etc. J'apprends toujours, mais je n'ai pas de personne physique qui puisse me montrer quoi que ce soit. Son tout de livres / tutoriels et essais et erreurs.

D'après ce que j'ai lu en ligne, il semble que ce gitsoit la meilleure chose à savoir, mais c'est aussi plus compliqué. Je ne veux pas me submerger. Dois-je continuer à maîtriser svn avant de passer à git ou serais-je plus sage de passer à git maintenant?

Y a-t-il des avantages et des inconvénients aux deux approches?

Non

Git est tellement différent de SVN qu'il ne vous aidera pas. Si quoi que ce soit, vous rechercherez des commandes "mise à jour" et "commit" et vous vous demanderez pourquoi tout est différent.

Commencez avec Git de bas en haut et continuez à partir de là.

La comparaison d'un système de versionnage de modèle de mise à jour / validation centralisé standard avec Git revient à comparer un bus avec le transport en commun. Un bus vous emmènera (et tout le monde) du point A au point B en utilisant exactement le même itinéraire. Le transport en commun vous amènera du point A au point B en utilisant l'itinéraire que vous souhaitez.

La distribution elle-même présente des inconvénients dont vous devez être conscient. Il faut plus de travail pour garder tout le monde sur la même page. Il offre cependant une énorme augmentation de la flexibilité.

Hashs de révision vs nombres

Quelqu'un a mentionné que Git utilise des hachages SHA1 tandis que Hg utilise des nombres.

D'abord, vous avez rarement (voire jamais) besoin de traiter directement les hachages dans les commits / pulls quotidiens. Vous devez remonter le journal et tirer des hachages si vous faites des différences ou certains des éléments de rebasage les plus délicats.

Avec Git, tout le monde a les mêmes hachages. Différents référentiels n'ont pas de numéros de validation différents et tout le monde est sur la même page. Avec le Hg, cela l'est moins. En pratique, si vous devez extraire les hachages de validation et travailler avec eux (que ce soit pour comparer ou parcourir la chronologie du code), il est plus facile de synchroniser avec d'autres personnes lorsque vous avez des hachages au lieu de nombres.

Non, je t'en prie, ne t'embête pas.

Sérieusement, commencez par un DVCS. Le fait que SVN soit populaire n'en fait pas la norme. Linus Torvalds vous dirait que cela pourrait pourrir votre cerveau .

Lisez cet excellent article / introduction de Joel Spolsky intitulé Subversion Re-education .

Vous pourriez également être intéressé par la lecture de cette autre question: je suis un geek de Subversion, pourquoi devrais-je considérer ou non Mercurial ou Git ou tout autre DVCS?

Choisir entre DVCS

Personnellement, j'utilise à la fois mercurial et git, et je pense qu'il est important de connaître les deux. Une lecture recommandée à ce sujet est Git vs Mercurial: Please Relax (voir l'exemple git-addremove). Deux citations de cet article qui, je pense, le résument.

Concernant git:

La philosophie de conception de Git est incontestablement celle d'Unix: contrairement à Subversion, CVS ou Mercurial, git n'est pas un binaire monolithique mais une multitude d'outils individuels, allant des commandes de haut niveau «porcelaine» telles que git-pull, git-merge et git-checkout aux commandes de plomberie de bas niveau telles que git-apply, git-hash-object et git-merge-file. Ainsi, comme MacGyver, vous pouvez faire à peu près tout ce dont vous avez besoin avec Git - cela inclut des moteurs Wiki totalement impressionnants, des trackers de problèmes, des systèmes de fichiers, des outils sysadmin - tout ce qui ne nécessite pas de réparation de fusible.

Concernant mercurial:

Les développeurs qui aiment garder leur système propre apprécieront probablement le fait que hg installe un binaire contrairement aux 144 qui composent git, et les développeurs qui pensent que la capacité de git à éditer vos validations précédentes est idiot, inutile et dangereux apprécieront le hg de simplicité fournit en omettant cette caractéristique particulière.

De nombreux projets peuvent être trouvés sur github et git est plus puissant, mais il peut également être quelque peu intimidant pour les nouveaux arrivants, en particulier les utilisateurs de Windows. Il y a aussi bitbucket (l'équivalent de github pour mercurial).

Ma recommandation: commencez par mercurial et dès que vous vous sentez à l'aise, prenez git; il ne s'agit pas des outils, il s'agit des gens avec qui vous travaillez .

Ce que je considère comme une utilisation réelle et pratique de subversion n'est pas pour travailler avec d'autres personnes, mais peut-être pour implémenter un programme de mise à jour pour vos applications de production, voici pourquoi:

• Actuellement, svn est presque installé dans la plupart des fournisseurs d'hébergement
• A un bon support de sous-projet (adressable dans git et hg maintenant, cependant). svn upet votre projet et ses dépendances sont mis à jour.

Citant Thorbjørn sur cet autre fil :

Les DVC sont à Subversion, ce que Bittorrent est à ftp

Edit : S'il y a un VCS que vous devez connaître avant Git, cela pourrait être Mercurial (interface CLI beaucoup plus conviviale et bonne pour se familiariser avec les concepts distribués). Ce conseil s'applique spécialement à ceux qui viennent de Subversion car la CLI est également similaire dans une certaine mesure. Le contrôle de version distribué peut être plus facile à apprendre que le contrôle de version centralisé, car vous vous préoccupez simplement de votre instance de référentiel, et non des parties client et serveur séparément .

Vous devriez apprendre ce que vous comptez utiliser. Git est populaire, tout comme Mercurial jouissait également d'une certaine popularité. Git / Mercurial sont tous deux des systèmes de contrôle de source distribués.

La chose la plus importante lors de l'introduction d'un nouveau concept à une équipe (et il est regrettable que le contrôle de version soit considéré comme un nouveau sujet pour trop d'équipes), il aide à définir vos objectifs et vos critères d'évaluation. Vous n'avez pas besoin d'être super formel à ce sujet, mais posez-vous les questions suivantes:

• Quel est le but du contrôle de version dans notre équipe. Oui, tous les systèmes de contrôle de version valant quoi que ce soit vous permettront de revenir dans l'histoire et de voir ce qui a changé dans un fichier donné. Cependant, allez-vous l'utiliser pour référencer les nouvelles versions? (hoche la tête, tu le veux). Ceci est l'énoncé de vision de 2-3 lignes pour ce que vous voulez accomplir.
• Votre équipe a-t-elle l'habitude d'avoir son propre environnement de travail local pour fusionner soigneusement les choses plus tard? Si tel est le cas, l'itinéraire DVCS pourrait être plus logique.
• À l'inverse, votre équipe a-t-elle l'habitude de travailler à partir d'un lecteur partagé et tout est en constante intégration? Si c'est le cas, le VCS plus traditionnel pourrait avoir le plus de sens.

Lors de l'évaluation de vos alternatives, vous devez considérer les choses importantes que tout VCS doit faire:

• Code de base (branches étiquetées, étiquettes, etc.). Fondamentalement, comment obtenez-vous le code source exact utilisé dans une version de votre projet.
• Obtenez les modifications locales sur le serveur central. Il doit y avoir une copie faisant autorité du code - que vous utilisiez DVCS ou VCS standard. Chaque outil traite ce processus différemment.
• Obtenez les modifications du serveur central sur votre copie locale.
• Comment gérer les changements expérimentaux. Les VCS vous permettent d'être plus audacieux avec les changements proposés sans casser le code source du projet principal. Les systèmes DVCS et VCS standard abordent cela très différemment - l'un d'entre eux fonctionnera le mieux pour votre équipe.
• Comment installez-vous et configurez-vous les serveurs?
• Avez-vous besoin d'une authentification? Si oui, comment vous assurez-vous que seules les personnes autorisées à apporter des modifications le peuvent?

En fin de compte, faites une évaluation rapide pour déterminer si les systèmes VCS ou DVCS standard seront les meilleurs pour votre équipe. Vous devrez choisir l'outil qui fournit le moins de douleur ou il ne sera probablement pas adopté. Après cela, évaluez vos alternatives qui correspondent le mieux à vos besoins.

À la fin, apprenez ce que vous avez l'intention d'utiliser.

Je pense que beaucoup de gens trouvent git plus compliqué que svn parce que c'est différent. Après avoir utilisé la subversion (ou les cv, etc.) pendant un certain temps, il peut être difficile de basculer mentalement les modes dans un modèle DVCS. Sur cette base, je dirais qu'il peut vous incomber de rechercher des VCS traditionnels comme la subversion en tandem avec la recherche d'un DVCS comme git.

Bien que git soit mon VCS préféré, je dirais qu'il est probablement préférable d'apprendre également la subversion. D'une part, il existe encore de nombreux référentiels de subversion et de cvs avec lesquels vous devrez peut-être interagir un jour, et vous aurez également une meilleure compréhension des avantages et des inconvénients précis du DVCS par rapport au VCS traditionnel.

Il serait contre-productif d'apprendre svn puis git

Voici quelques raisons:

• Gits radicalement différents de svn. Git est distrait et svn est client / serveur.
• Différentes significations sont attachées aux mêmes mots. Par exemple, «git checkout ...» a une signification différente de «svn checkout ...»
• La ramification est différente. Git a ce concept de branches 'topic' qui sont des branches locales bon marché que svn ne supporte pas.
• Git a un emplacement supplémentaire, appelé index, qui se situe entre l'arborescence de travail et votre référentiel. Svn n'a pas d'index. Avec git, vos modifications passent de votre arborescence de travail à l'index et au référentiel.

Mon conseil est d'apprendre juste git.

Il y a certaines choses globalement les mêmes dans GIT et SVN et d'autres non.

Créer / mettre à jour / extraire / valider

En gros la même chose, vous devriez le ramasser facilement.

comment étiqueter et créer des branches, mais encore beaucoup de confusion sur les conflits entre les branches et le tronc, etc.

Différent entre les deux.

Je ne dis pas que vous devriez ou ne devriez pas changer maintenant (je pense que c'est votre appel), je voulais juste le souligner car c'est quelque chose à prendre en compte. Si vous êtes sûr de vouloir essayer Git, vous pouvez décider de passer maintenant pour vous éviter d'apprendre quelque chose dans SVN qui est différent dans Git.

Sensationnel; 12 réponses et tout le monde pose toujours la question ...

Non, Subversion n'est pas une condition préalable à Git.

Il n'y a pas de correspondance claire entre Subversion et Git - si vous prévoyez d'apprendre les deux, vous n'aurez qu'à souffrir du fait qu'ils utilisent les mêmes termes pour différentes actions. (Et des termes différents pour les mêmes actions.)

• svn commitest une chose différente que git commit.
• les branches dans svn et git sont très différentes
• un dépôt svn ressemble plus à une télécommande git (mais pas vraiment)
• un dépôt git ressemble plus à une copie de travail svn (mais pas vraiment)

Ce sont deux outils divisés par un langage commun.

Votre question et la plupart des autres réponses supposent que git est une sorte de svn ++; Un "meilleur svn". Ça ne l'est pas. Les deux sont des outils différents qui fonctionnent dans le même espace, comme une voiture et une moto.

Je vous suggère d'en choisir un, de le maîtriser et de commencer à l'utiliser dans votre équipe. L'apprentissage du contrôle de version va être difficile pour les personnes qui ne l'ont pas utilisé auparavant. Votre VCS va être un élément important de votre infrastructure, et apprendre à lui faire confiance implique de développer de nouvelles habitudes de travail. Cela prend du temps.

(Dans tous les cas, assurez-vous que vos administrateurs système sauvegardent le référentiel maître - perdre votre contrôle de source serait catastrophique.)

Probablement pas - il y a suffisamment de différences entre les serveurs et les serveurs distribués que vous ne feriez que vous embrouiller davantage.

Commencez dès le départ à suivre les bonnes pratiques avec le DVCS de votre choix comme si vous étiez à partir de zéro et vous serez probablement beaucoup plus heureux.

Allez voir Mercurial (si vous ne voulez pas être dépassé).

Git n'est que légèrement plus compliqué que Subversion, car il existe une distinction dans Git entre la validation et la transmission au référentiel central.

Cela vaut la peine d'apprendre Git pendant que vous avez la chance d'avoir l'esprit détruit par Subversion.

Je ne pense pas que la compréhension de Subversion soit nécessaire pour comprendre Git.

La plus grande différence avec Git et Mercurial de Subversion, du moins pour moi, c'est que vous avez un référentiel local avec lequel vous travaillez, vous y connectez et en sortez jusqu'à ce que votre code fonctionne, vous passez la commande à partir du référentiel central, corrigez tous les conflits et réenregistrer et pousser vers le serveur.

J'aime vraiment git dans l'environnement Unix (Linux, MacOS X). Sous Windows, c'est un peu hacky. Je considérerais Mercurial si j'ai Windows dans l'équation.

Si vous avez aimé vos cours d'histoire, essayez SCCS, RCS, CVS, Subversion, puis utilisez quelque chose d'utile comme Git ou Mercurial.

Git et Mercurial sont equipotents, le gros bonus de Git est github . Mais si vous ne voulez pas externaliser votre contrôle de version, github n'est plus dans l'équation.

Les systèmes de contrôle de version partagent quelque chose en commun avec les langages de programmation dans la mesure où le premier que vous apprenez prendra le plus de temps. Après cela, en choisir un nouveau est juste une question d'apprendre comment les concepts de base sont exprimés par le nouveau système.

Vous pouvez apprendre Git maintenant et investir plus de temps dans l'apprentissage de Suvbersion plus tard si vous en avez besoin.

Nan. Téléchargez Git, créez un compte github et amusez-vous pendant quelques jours à forker les dépôts, etc. Git est assez simple à utiliser. Apprenez 5 ou 6 commandes bash et vous pouvez effectuer toutes les tâches essentielles. Je préfère généralement la «protection contre les idiots» d'une interface graphique, mais le Git Bash est à peu près aussi simple que possible. De plus, le Git Gui est assez décent si vous préférez cet itinéraire. Je ne vois pas vraiment l'avantage que vous verriez en apprenant SVN. J'ai traversé une période il y a quelque temps où j'évaluais plusieurs systèmes de contrôle de version différents pour un nouveau projet open source. J'ai essayé SVN, Bazaar, Git et quelques autres et j'ai appris les bases de chacun. YMMV, mais Git était de loin le plus facile. Il n'y a rien de mal à apprendre SVN également, mais cela ne vous aidera vraiment pas à apprendre Git.