Git vs Team Foundation Server
J'ai présenté Git à mon équipe de développement et tout le monde le déteste, sauf moi. Ils veulent le remplacer par Team Foundation Server. J'ai l'impression que c'est un énorme pas en arrière, même si je ne connais pas très bien TFS. Une personne expérimentée peut-elle comparer le support de branche sur TFS à celui de Git? De plus, en général, quels sont les avantages et les inconvénients de TFS? Est-ce que je vais le détester après avoir utilisé Git pendant quelques années?
Je pense que la déclaration
tout le monde déteste sauf moi
rend toute discussion inutile: lorsque vous continuez à utiliser Git, ils vous blâmeront si quelque chose ne va pas.
En dehors de cela, Git a pour moi deux avantages par rapport à un VCS centralisé que j'apprécie le plus (comme décrit en partie par Rob Sobers ):
- sauvegarde automatique de l'ensemble du référentiel: chaque fois que quelqu'un extrait du référentiel central, il/elle obtient un historique complet des modifications. Quand un dépôt est perdu: ne vous inquiétez pas, prenez l’un de ceux présents sur chaque poste de travail.
- accès au dépôt hors ligne: lorsque je travaille à la maison (ou dans un avion ou un train), je peux voir l'historique complet du projet, chaque checkin, sans démarrer ma connexion VPN au travail et peut travailler comme je étais au travail: checkin, checkout, branch, n'importe quoi.
Mais comme je l'ai dit: je pense que vous menez une bataille perdue: quand tout le monde déteste Git, n'utilisez pas Git. Cela pourrait vous aider davantage à savoir pourquoi ils détestent Git au lieu de les essayer de les convaincre.
S'ils n'en veulent tout simplement pas parce que c'est nouveau pour eux et ne veulent pas apprendre quelque chose de nouveau: êtes-vous sûr de réussir le développement avec ce personnel?
Est-ce que chaque personne déteste vraiment Git ou est-elle influencée par certains leaders d'opinion? Trouvez les dirigeants et demandez-leur quel est le problème. Convainquez-les et vous convaincrez le reste de l'équipe.
Si vous ne pouvez pas convaincre les dirigeants: oubliez d'utiliser Git, prenez le TFS. Vous facilitera la vie.
La principale différence entre les deux systèmes est que TFS est un système de contrôle de version centralisé et Git est un système de contrôle de version distribué.
Avec TFS, les référentiels sont stockés sur un serveur central et les développeurs extraient une copie de travail, qui est un instantané du code à un moment donné. Avec Git, les développeurs clonent le référentiel entier sur leurs machines, y compris tout l'historique.
L'un des avantages de disposer du référentiel complet sur les machines de votre développeur est la redondance en cas de panne du serveur. Un autre avantage de Nice est que vous pouvez déplacer votre copie de travail entre les révisions sans jamais parler au serveur, ce qui peut être utile si le serveur est en panne ou tout simplement inaccessible.
Pour moi, le véritable avantage est que vous pouvez valider des jeux de modifications dans votre référentiel local sans jamais parler au serveur ni infliger de modifications potentiellement instables à votre équipe (c'est-à-dire , briser la construction).
Par exemple, si je travaille sur une grosse fonctionnalité, il me faudra peut-être une semaine pour la coder et la tester complètement. Je ne veux pas enregistrer de code instable en milieu de semaine et interrompre la construction, mais que se passe-t-il si je me rapproche de la fin de la semaine et que je coche accidentellement toute ma copie de travail? Si je ne m'engage pas depuis toujours, je risque de perdre mon travail. Ce n'est pas un contrôle de version efficace, et TFS est sensible à cela.
Avec DVCS, je peux commettre en permanence sans craindre de casser la construction, car je commets mes modifications localement. Dans TFS et d'autres systèmes centralisés, il n'y a pas de concept d'enregistrement local.
Je ne me suis même pas déjà rendu compte à quel point la création de branches et de fusions est bien meilleure dans DVCS, mais vous pouvez trouver des tonnes d'explications ici sur SO ou via Google. Je peux vous dire par expérience que la création de branches et la fusion dans TFS n’est pas une bonne chose.
Si l'argument en faveur de TFS dans votre organisation est que cela fonctionne mieux sous Windows que Git, je suggérerais Mercurial, qui fonctionne très bien sous Windows: l'intégration à l'Explorateur Windows (TortoiseHg) et à Visual Studio (VisualHg).
Les gens doivent poser leur arme, s'éloigner du rebord et réfléchir pendant une minute. Il s'avère que le DVCS présente des avantages objectifs, concrets et indéniables qui feront une énorme différence dans la productivité d'une équipe.
Tout se résume à la ramification et à la fusion.
Avant DVCS, le principe directeur était "Priez Dieu que vous n'ayez pas à créer de branches et à fusionner. Et si vous le faites, au moins le prier de laisser les choses devenir très, très simples."
Maintenant, avec DVCS, les ramifications (et la fusion) sont tellement améliorées, le principe directeur est le suivant: "Faites-le en un tour de main. Il vous apportera une tonne d'avantages et ne vous causera pas problèmes."
Et c’est un énorme gain de productivité pour toute équipe.
Le problème est que, pour que les gens comprennent ce que je viens de dire et soient convaincus que c’est vrai, ils doivent d’abord investir dans une petite courbe d’apprentissage. Ils n'ont pas à apprendre Git ni aucun autre DVCS lui-même ... ils doivent juste apprendre comment Git crée des branches et des fusions. Lisez et relisez certains articles et billets de blog, en ralentissant et en passant au travers jusqu'à ce que vous le voyiez. Cela pourrait prendre la majeure partie de 2 ou 3 jours complets.
Mais une fois que vous verrez cela, vous n’envisagerez même pas de choisir un non-DVCS. Parce que le DVCS présente des avantages clairs, objectifs et concrets, et que les plus grandes victoires concernent les branches et les fusions.
Original : @Rob, TFS a quelque chose qui s'appelle " Shelving " et qui répond à votre préoccupation de ne pas engager de travaux en cours sans cela. affectant la construction officielle. Je me rends bien compte que le contrôle de version central est un obstacle, mais en ce qui concerne TFS, l’inscription de votre code dans l’étagère peut être considérée comme une force, puis le serveur central dispose d’une copie de votre travail en cours dans le cas rare. votre machine locale se bloque ou est perdue/volée ou vous devez changer de vitesse rapidement. Mon point est que TFS devrait recevoir les éloges appropriés dans ce domaine. En outre, la création de branches et la fusion dans TFS2010 ont été améliorées par rapport aux versions précédentes. La version à laquelle vous faites référence n'apparaît pas clairement lorsque vous dites "... par expérience, la création de branches et la fusion dans TFS ne sont pas bonnes". Avertissement: Je suis un utilisateur modéré de TFS2010.
Edit Dec-5-2011 : Pour le PO, l’un des problèmes qui me préoccupent à propos de TFS est qu’il insiste pour que tous vos fichiers locaux soient configurés en "lecture". seulement "quand vous ne travaillez pas sur eux. Si vous souhaitez apporter une modification, le flux consiste à "extraire" le fichier, ce qui efface simplement l'attribut en lecture seule sur le fichier afin que TFS sache le surveiller. C'est un flux de travail gênant. Je préférerais que cela fonctionne est qu'il détecte automatiquement si j'ai apporté une modification et ne s'inquiète pas du tout des attributs de fichier. De cette façon, je peux modifier le fichier dans Visual Studio, dans le Bloc-notes ou avec l’outil de mon choix. Le système de contrôle de version devrait être aussi transparent que possible à cet égard. Il existe une extension de l'Explorateur Windows ( TFS PowerTools ) qui vous permet de travailler avec vos fichiers dans l'Explorateur Windows, mais cela ne simplifie pas beaucoup le flux de travail.
En plus de tout ce qui a été dit (
https://stackoverflow.com/a/4416666/172109
), ce qui est correct, TFS n'est pas qu'un VCS. Une fonctionnalité majeure fournie par TFS est la fonctionnalité de suivi des bogues intégrée en mode natif. Les changesets sont liés à des problèmes et peuvent être suivis. Diverses stratégies d’archivage sont prises en charge, ainsi que l’intégration avec le domaine Windows, comme le font les utilisateurs de TFS. L’interface graphique parfaitement intégrée avec Visual Studio est un autre argument de vente qui séduit moins que la moyenne souris et cliquez sur développeur et son gestionnaire.
Par conséquent, comparer Git à TFS n’est pas une bonne question à poser. La question correcte, bien que peu pratique, consiste à comparer Git à la seule fonctionnalité VCS de TFS. À cela, Git souffle TFS hors de l'eau. Cependant, toute équipe sérieuse a besoin d’autres outils et c’est là que TFS fournit une destination unique.
Si votre équipe utilise TFS et que vous souhaitez utiliser Git, vous pouvez envisager un pont "git to tfs". Vous travaillez essentiellement au quotidien avec Git sur votre ordinateur, puis lorsque vous souhaitez transmettre vos modifications, vous les transmettez au serveur TFS.
Il y a un couple là-bas (sur github). J'en ai utilisé un à ma dernière place (avec un autre développeur) avec un certain succès. Voir:
Après une enquête entre le pour et le contre, l’entreprise dans laquelle je participais a également décidé de faire appel à TFS. Non pas parce que GIT n'est pas un bon système de contrôle de version, mais surtout pour la solution ALM entièrement intégrée fournie par TFS. Si seule la fonctionnalité de contrôle de version était importante, le choix aurait probablement été GIT. La courbe d’apprentissage GIT raide pour les développeurs réguliers peut toutefois ne pas être sous-estimée.
Voir une explication détaillée dans mon article de blog TFS en tant que véritable plate-forme multi-technologie .
Le tout distribué de Git est vraiment génial. Il offre quelques fonctionnalités que les tablettes n’ont pas (dans le produit actuel) telles que les options de restauration et de validation locales (telles que fonctionnalité d’historique local d’Eclipse ). Vous pouvez alléger ce problème en utilisant des branches de développeur, mais soyons honnêtes, de nombreux développeurs n'aiment pas créer de branches et fusionner un bit. On m'a demandé d'activer trop souvent l'ancienne fonctionnalité de "paiement exclusif" à l'ancienne (et de la refuser à chaque fois).
Je pense que beaucoup de grandes entreprises ont très peur de permettre à un développeur de simplement importer toute l'histoire dans un espace de travail local et de l'emmener avec lui (vers un nouvel employeur, par exemple) ... Voler un instantané est mauvais, mais enlever toute une histoire est encore plus gênant. (Non pas que vous ne puissiez pas obtenir un historique complet de TFS de vous le vouliez) ...
Il est mentionné que c'est un excellent moyen de sauvegarde, ce qui est excellent pour l'Open Source où le responsable de la maintenance d'origine pourrait arrêter de prendre soin de sa version et la supprimer, mais pour un plan d'entreprise, cela est encore une fois un échec pour de nombreuses entreprises car aucune responsabilité n'est clairement définie. garder des sauvegardes. Et il serait difficile de déterminer quelle version utiliser si le "projet" principal disparaît de façon ou d'autre. Ce qui tendrait à nommer un référentiel comme principal/central.
Ce que j'aime le plus à propos de Git, c'est l'option Push/Pull, où vous pouvez facilement contribuer au code d'un projet sans avoir besoin de droits de validation. J'imagine que vous pourriez utiliser un nombre très limité d'utilisateurs et de tablettes dans TFS pour imiter cela, mais ce n'est pas aussi puissant que l'option Git. Le branchement de plusieurs projets d’équipe peut également s’avérer utile, mais d’un point de vue administratif, de nombreuses organisations ne sont pas réellement réalisables, car l’ajout de projets d’équipe augmente considérablement les frais généraux d’administration.
J'aimerais également ajouter quelque chose aux choses mentionnées dans la zone de contrôle de source non. Des fonctionnalités telles que le suivi des éléments de travail, la génération de rapports et l'automatisation de la construction (y compris la gestion de laboratoire) bénéficient grandement d'un référentiel central de premier plan. Celles-ci deviennent beaucoup plus difficiles lorsque vous utilisez un modèle purement distribué, à moins que l'un des nœuds soit en tête (et que vous retourniez donc à un modèle moins distribué).
Si TFS Basic arrive avec TFS 11, il n’est peut-être pas inutile d’attendre un TFS distribué qui vous permette de synchroniser votre TFS Basic local avec un TFS central à l’ère TFS 12+. Je vais mettre mon votez pour cela dans le service utilisateur !
Pour moi, la principale différence est que tous les fichiers auxiliaires que TFS ajoutera à votre solution (.vssscc) pour "prendre en charge" TFS - nous avons récemment eu des problèmes avec la mise en correspondance de ces fichiers avec la mauvaise branche, ce qui conduit à un débogage intéressant. ...