J'ai présenté Git à mon équipe de développeurs 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 suis pas très familier avec TFS. Une personne expérimentée peut-elle comparer la prise en charge de la branche sur TFS à la branche Git? De plus, en général, quels sont les avantages et les inconvénients de TFS? Vais-je le détester après avoir utilisé Git pendant quelques années?
263
Réponses:
Je pense que la déclaration
rend toute discussion inutile: lorsque vous continuez à utiliser Git, ils vous blâmeront en cas de problème.
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 ):
Mais comme je l'ai dit: je pense que vous livrez 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 ne le veulent tout simplement pas parce que c'est nouveau pour eux et ne sont pas disposés à apprendre quelque chose de nouveau: êtes-vous sûr que vous réussirez 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 leaders 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 source
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 récupèrent une copie de travail, qui est un instantané du code à un moment précis. Avec Git, les développeurs clonent l' intégralité du référentiel sur leurs machines, y compris l'ensemble de l'historique.
Un avantage d'avoir le référentiel complet sur les machines de votre développeur est la redondance au cas où le serveur mourrait. Un autre avantage intéressant 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 simplement inaccessible.
Pour moi, la véritable aubaine est que vous pouvez valider des ensembles de modifications dans votre référentiel local sans jamais parler au serveur ou infliger des modifications potentiellement instables à votre équipe (c'est-à-dire rompre la build).
Par exemple, si je travaille sur une grosse fonctionnalité, cela pourrait prendre une semaine pour coder et tester complètement. Je ne veux pas archiver le code instable en milieu de semaine et interrompre la construction, mais que se passe-t-il si je m'approche de la fin de la semaine et que je falsifie accidentellement l'intégralité de ma copie de travail? Si je ne m'engage pas depuis le début, je risque de perdre mon travail. Ce n'est pas un contrôle de version efficace, et TFS y est sensible.
Avec DVCS, je peux m'engager constamment sans me soucier de casser la construction, car je valide mes modifications localement . Dans TFS et d'autres systèmes centralisés, il n'y a pas de concept d'enregistrement local.
Je ne suis même pas allé dans la mesure où la branche et la fusion sont meilleures en DVCS, mais vous pouvez trouver des tonnes d'explications ici sur SO ou via Google. Je peux vous dire par expérience que le branchement et la fusion dans TFS n'est pas bon.
Si l'argument pour TFS dans votre organisation est qu'il fonctionne mieux sur Windows que Git, je suggère Mercurial, qui fonctionne très bien sur Windows - il existe une intégration avec Windows Explorer (TortoiseHg) et Visual Studio (VisualHg).
la source
Les gens doivent poser le pistolet, 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 pour que vous n'ayez pas à vous ramifier et à fusionner. Et si vous le faites, au moins le priez de le laisser être très, très simple."
Maintenant, avec DVCS, le branchement ( et la fusion ) est tellement améliorée, le principe directeur est: "Faites-le à la légère. Cela vous donnera une tonne d'avantages et ne vous causera aucun problème."
Et c'est un ÉNORME booster de productivité pour n'importe quelle é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 ou tout autre DVCS lui-même ... ils ont juste besoin d'apprendre comment Git fait des branchements et des fusions. Lisez et relisez certains articles et articles de blog, en le prenant lentement et en le parcourant 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 ne songerez même pas à choisir un non-DVCS. Parce qu'il y a vraiment des avantages clairs, objectifs et concrets au DVCS, et les plus gros gains sont dans le domaine de la ramification et de la fusion.
la source
Original : @Rob, TFS a quelque chose appelé " Rayonnage " qui répond à votre préoccupation concernant la validation des travaux en cours sans que cela affecte la version officielle. Je me rends compte que vous voyez le contrôle de version central comme un obstacle, mais en ce qui concerne TFS, la vérification de votre code dans l'étagère peut être considérée comme une force b / c, puis le serveur central a une copie de votre travail en cours dans le cas rare votre machine locale plante ou est perdue / volée ou vous devez changer de vitesse rapidement. Mon point est que TFS devrait recevoir des éloges appropriés dans ce domaine. En outre, la ramification et la fusion dans TFS2010 ont été améliorées par rapport aux versions précédentes, et il n'est pas clair à quelle version vous faites référence lorsque vous dites "... par expérience que la ramification et la fusion dans TFS ne sont pas bonnes." Avertissement: je suis un utilisateur modéré de TFS2010.
Edit 5 décembre 2011 : Pour l'OP, une chose qui me dérange à propos de TFS est qu'il insiste pour définir tous vos fichiers locaux en "lecture seule" lorsque vous ne travaillez pas dessus. Si vous souhaitez apporter une modification, le flux est que vous devez "extraire" le fichier, qui efface simplement l'attribut en lecture seule sur le fichier afin que TFS sache le garder à l'œil. C'est un flux de travail peu pratique. La façon dont je préférerais que cela fonctionne est qu'il détecte simplement automatiquement si j'ai apporté une modification et ne se soucie pas du tout des attributs de fichier. De cette façon, je peux modifier le fichier soit dans Visual Studio, soit dans le Bloc-notes, soit avec l'outil que je souhaite. Le système de contrôle des versions doit être aussi transparent que possible à cet égard. Il existe une extension Windows Explorer ( TFS PowerTools) qui vous permet de travailler avec vos fichiers dans l'Explorateur Windows, mais cela ne simplifie pas beaucoup le flux de travail.
la source
En plus de tout ce qui a été dit (
), ce qui est correct, TFS n'est pas seulement un VCS. L'une des principales fonctionnalités de TFS est la fonctionnalité de suivi des bogues intégrée de manière native. Les ensembles de modifications sont liés à des problèmes et pourraient être suivis. Diverses politiques pour les enregistrements sont prises en charge, ainsi que l'intégration avec le domaine Windows, ce que les personnes qui exécutent TFS ont. L'interface graphique étroitement intégrée avec Visual Studio est un autre argument de vente, qui fait appel à
moins que la moyennedes développeurs de souris et de clics et de son manager.Par conséquent, comparer Git à TFS n'est pas une bonne question à poser. La question correcte, bien que peu pratique, est de comparer Git avec seulement la 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.
la source
Si votre équipe utilise TFS et que vous souhaitez utiliser Git, vous pouvez envisager un pont "git vers tfs". Essentiellement, vous travaillez au jour le jour en utilisant Git sur votre ordinateur, puis lorsque vous souhaitez pousser vos modifications, vous les envoyez au serveur TFS.
Il y en a quelques là-bas (sur github). J'en ai utilisé un à ma dernière place (avec un autre développeur) avec un certain succès. Voir:
https://github.com/spraints/git-tfs
https://github.com/git-tfs/git-tfs
la source
Après une enquête entre le pour et le contre, la société avec laquelle j'ai été impliqué a également décidé d'opter pour 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 fonction de contrôle de version était importante, le choix aurait probablement été GIT. La courbe d'apprentissage GIT abrupte pour les développeurs réguliers ne doit cependant pas être sous-estimée.
Voir une explication détaillée dans mon article de blog TFS comme une véritable plate-forme multi-technologie .
la source
L'ensemble de la chose distribuée de Git est vraiment vraiment génial. il donne quelques fonctionnalités que les Shelvesets n'ont pas (dans le produit actuel) telles que les options de restauration et de validation locales (telles que la fonctionnalité d'historique local d'Eclipse ). Vous pouvez atténuer cela en utilisant des branches de développeur, mais soyons honnêtes, de nombreux développeurs n'aiment pas la branche et la fusion d'un bit. On m'a demandé d'activer la fonction de "paiement exclusif" à l'ancienne dans TFS trop souvent (et je l'ai refusée à chaque fois).
Je pense que de nombreuses grandes entreprises ont assez peur de permettre à un développeur de simplement apporter toute l'histoire dans un espace de travail local et de l'emmener avec eux (à un nouvel employeur par exemple) ... Voler un instantané est mauvais, mais enlever toute une histoire est encore plus gênant. (Pas que vous ne pouviez pas obtenir un historique complet de TFS de vous le vouliez) ...
Il est mentionné que c'est un excellent moyen de sauvegarder, ce qui est idéal pour l'open source à nouveau où le mainteneur d'origine peut s'arrêter pour se soucier et supprime sa version, mais pour un plan d'entreprise, cela échoue à nouveau pour de nombreuses entreprises car il n'y a pas d'attribution de responsabilité claire pour garder des sauvegardes. Et il serait difficile de déterminer quelle version utiliser si le «projet» principal disparaît d'une manière ou d'une autre. Ce qui aurait tendance à désigner 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 du code à un projet sans avoir besoin de droits de validation. Je suppose que vous pourriez utiliser des utilisateurs et des étagères très limités dans TFS pour imiter cela, mais ce n'est pas aussi puissant que l'option Git. Le branchement entre projets d'équipe peut également fonctionner, mais d'un point de vue administratif, ce n'est pas vraiment faisable pour de nombreuses organisations, car l'ajout de projets d'équipe ajoute beaucoup de frais administratifs.
Je voudrais également ajouter aux choses mentionnées dans la zone de contrôle non source. Des fonctionnalités telles que le suivi des éléments de travail, les 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 distribué pur, à moins que vous ne fassiez passer l'un des nœuds (et revenez ainsi à un modèle moins distribué).
Avec TFS Basic fourni avec TFS 11, il n'est peut-être pas loin de s'attendre à un TFS distribué qui vous permet de synchroniser votre TFS de base local avec un TFS central à l'ère TFS 12+. Je mettrai mon vote pour cela dans le service utilisateur !
la source
checkincommande (au lieu de rcheckin). Mais je préfère rcheckin parce que c'est plus la manière git de faire les choses et c'est pourquoi nous choisissons d'utiliser git;)Pour moi, la différence majeure réside dans tous les fichiers auxiliaires que TFS ajoutera à votre solution (.vssscc) pour `` prendre en charge '' TFS - nous avons eu des problèmes récents avec ces fichiers finissant mappés sur la mauvaise branche, ce qui conduit à un débogage intéressant ...
la source
.gitdossier pour suivre tous les détails du référentiel. TFS modifiera au minimum vos fichiers.sln(ou s'agit-il du.csproj?) Pour y placer l'emplacement du référentiel distant.