Git vs Team Foundation Server [fermé]]
j'ai présenté Git à mon équipe de développement, et tout le monde le déteste sauf moi. Ils veulent remplacer il avec le serveur de la fondation de L'équipe. J'ai l'impression que c'est un grand pas en arrière, bien que je ne sois pas très familier avec le TFS. Est-ce que quelqu'un avec de l'expérience peut comparer le support de branchement sur TFS à branchement Git? En outre, en général, quels sont les avantages et les inconvénients de la TFS? Vais-je déteste après utiliser Git pendant quelques années?
9 réponses
je pense, la déclaration
tout le monde le hait sauf moi
rend toute discussion ultérieure inutile: quand vous continuez à utiliser Git, ils blâmeront vous si quelque chose va mal.
en outre, pour moi, Git a 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 de la pension: chaque fois que quelqu'un tire de la pension centrale, il/elle obtient une histoire complète des changements. Quand un repo se perd: ne vous inquiétez pas, prenez un de ceux présents sur chaque poste de travail.
- offline repo access: quand je travaille à la maison (ou dans un avion ou un train), je peux voir l'histoire complète du projet, chaque checkin simple, sans démarrer ma connexion VPN au travail et peut fonctionner comme je étaient au travail: checkin, checkout, branche, n'importe quoi.
mais comme je l'ai dit: je pense que vous menez une bataille perdue: quand tout le monde hait Git, ne pas utiliser Git. Il pourrait vous aider plus de savoir pourquoi ils détestent Git au lieu de les essayer de les convaincre.
S'ils ne 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 va faire le succès du développement avec l'équipe?
est-ce que tous les individus détestent Git ou sont-ils influencés par certains leaders d'opinion? Trouver les responsables et demandez-leur quel est le problème. Convaincre et vous allez convaincre le reste de l'équipe.
si vous ne pouvez pas convaincre les dirigeants: oubliez d'utiliser Git, prenez le TFS. Rendra votre vie plus facile.
la principale différence entre les deux systèmes est que TFS est un système centralisé de contrôle de version et Git est un système de contrôle de version distribué.
avec TFS, les dépôts sont stockés sur un serveur central et les développeurs vérifient une copie de travail, qui est un snapshot du code à un moment précis. Avec Git, les développeurs clonent le dépôt entier à leurs machines, y compris toute l'histoire.
L'un des avantages d'avoir le dépôt complet sur les machines de votre développeur est la redondance en cas de panne du serveur. Un autre avantage est que vous pouvez déplacer votre copie de travail d'une révision à l'autre 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 commit modifier les paramètres de votre dépôt local sans jamais parler à la serveur ou d'infliger des changements potentiellement instables à votre équipe (c'est-à-dire casser la construction).
par exemple, si je travaille sur un gros objet, il me faudra peut-être une semaine pour le coder et le tester complètement. Je ne veux pas enregistrer le code instable en milieu de semaine et casser la construction, mais que se passe-t-il si j'approche de la fin de la semaine et que je pique accidentellement toute ma copie de travail? Si je n'ai pas fait de commettre tout le long je me tiens le risque de perdre mon travail. Ce n'est pas une version efficace contrôle, et TFS est sensible à cela.
avec DVCS, je peux m'engager constamment sans me soucier de casser la construction, parce que je commets mes modifications localement . Dans le 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 combien de mieux brancher et fusionner est dans les DVCS, mais vous pouvez trouver des tonnes d'explications ici sur SO ou via Google. Je peux vous dire par expérience que brancher et fusionner 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érerais Mercurial, qui fonctionne bien sur Windows -- il y a intégration avec Windows Explorer (TortoiseHg) et Visual Studio (VisualHg).
les gens doivent poser leur arme, s'écarter de la corniche, et penser pendant une minute. Il s'avère qu'il y a des avantages objectifs, concrets et indéniables pour les DVCS qui feront une énorme différence dans la productivité d'une équipe.
tout se résume à brancher et fusionner.
avant DVCS, le principe directeur était "Priez Dieu que vous n'ayez pas à vous brancher et fusionner. Et si vous le faites, au moins mendier pour que ce soit très, très simple."
maintenant, avec DVCS, branchement ( et fusion ) est tellement améliorée, le principe directeur est, " faites-le à la baisse d'un chapeau. Il vous donnera une tonne d'avantages et ne vous causera pas de problèmes."
et c'est un énorme booster de productivité pour toute équipe.
le problème est, pour les gens de comprendre ce que je viens de dire et être convaincu que c'est vrai, ils doivent d'abord investir dans un peu d'une courbe d'apprentissage. Ils n'ont pas à apprendre le Git ou tout autre DVCS lui-même ... ils ont juste besoin d'apprendre comment Git se ramifie et fusionne. Lisez et relisez des articles et des billets de blog, prenez votre temps, et travaillez dessus jusqu'à ce que vous le voyez. Ça pourrait prendre 2 ou 3 jours.
mais une fois que vous avez vu cela, vous n'envisagerez même pas de choisir un non-DVCS. Parce qu'il y a vraiment des avantages clairs, objectifs et concrets pour les DVCS, et les plus grandes victoires sont dans la zone de branchement et de fusion.
Original : @Rob, TSF a quelque chose qui s'appelle " Shelving " qui répond à votre préoccupation quant à la validation du travail en cours, sans que cela n'affecte la compilation officiel. Je sais que vous voyez le contrôle de version central comme un obstacle, mais en ce qui concerne TFS, vérifier votre code dans l'étagère peut être considéré comme une force b/C alors le serveur central a une copie de votre travail en cours dans le rare cas où votre machine locale plante ou est perdu/volé ou vous devez changer de vitesse rapidement. Mon point de vue est que TFS devrait être louangée comme il se doit dans ce domaine. De plus, la branchement et la fusion dans TFS2010 ont été améliorés par rapport aux versions précédentes, et il n'est pas clair à quelle version vous faites référence quand vous dites "... d'après l'expérience, la ramification et la fusion dans TFS n'est pas bonne."Avertissement: je suis un utilisateur modéré de TFS2010.
Edit Dec-5-2011 : pour L'OP, une chose qui me dérange au sujet de TFS est qu'il insiste sur paramétrer tous vos fichiers locaux à "lecture seule" lorsque vous ne travaillez pas sur eux. Si vous voulez faire un changement, le flux est que vous devez "vérifier" le fichier, qui efface juste l'attribut readonly sur le fichier afin que TFS sait garder un oeil dessus. C'est un inconvénient de flux de travail. La façon dont je préférerais qu'il fonctionne est que c'est détecte automatiquement si j'ai fait un changement et ne s'inquiète pas/se tracasse avec les attributs de fichier du tout. De cette façon, je peux modifier le fichier soit dans Visual Studio, ou Bloc-notes, ou avec n'importe quel outil que je veux. Le système de contrôle de version devrait être aussi transparent que possible à cet égard. Il y a une Extension de Windows Explorer ( TFS PowerTools ) qui vous permet de travailler avec vos fichiers dans Windows Explorer, mais qui 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 exact, TFS n'est pas juste un VCS. L'une des principales caractéristiques de TFS est: fonctionnalité nativement intégrée de suivi des bogues. Les changements sont liés aux problèmes et pourraient être suivis. Diverses politiques de check-in sont prises en charge, ainsi que l'intégration avec Windows domain, ce qui est ce que les personnes qui exécutent TFS ont. GUI étroitement intégré avec Visual Studio est un autre point de vente, qui fait appel à moins que la moyenne souris et cliquez sur le développeur et son directeur.
donc comparer Git à TFS n'est pas une bonne question à poser. La question correcte, bien qu'impraticable, est de comparer Git avec juste la fonctionnalité VCS de TFS. À ce moment-là, 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 à guichet unique.
si votre équipe utilise TFS et que vous voulez utiliser Git, vous pourriez envisager un pont" git to tfs". Essentiellement vous travaillez au jour le jour en utilisant Git sur votre ordinateur, puis quand vous voulez pousser vos modifications vous les poussez vers le serveur TFS.
Il y a un couple (sur github). J'ai utilisé un lors de 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, la société avec laquelle j'étais impliqué 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 que TFS fournit. Si seule la fonction de contrôle de version était importante, le choix aurait probablement été GIT. La courbe d'apprentissage raide GIT pour les développeurs réguliers ne peut toutefois pas être sous-estimée.
voir une explication détaillée sur mon blog post TFS comme une vraie-croix-plate-forme technologique .
l'ensemble distribué chose de Git est vraiment grand. il donne quelques caractéristiques Shelvesets n'ont pas (dans le produit actuel) comme le local rollback et commit options (comme Eclipse de caractéristique d'histoire locale ). Vous pourriez alléger cela en utilisant des branches de développeur, mais soyons honnêtes, beaucoup de développeurs n'aiment pas brancher et fusionner un peu. On m'a demandé d'activer l'ancienne fonctionnalité "exclusive checkout" dans TFS plusieurs fois de trop (et je l'ai nié) à chaque fois).
je pense que beaucoup de grandes entreprises sont assez effrayées pour permettre à un dev de simplement apporter toute l'histoire dans un espace de travail local et de le prendre avec eux (à 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 pouviez pas obtenir une histoire complète de TFS de vous l'avez voulu)...
il est mentionné que c'est une excellente façon de sauvegarder, qui est grande pour open source encore une fois où le mainteneur original pourrait s'arrêter de s'occuper et supprime sa version, mais pour un plan d'entreprise cela tombe encore une fois à court pour de nombreuses entreprises car il n'y a pas d'attribution claire de la responsabilité de garder les sauvegardes. Et il serait difficile de comprendre la version à utiliser si le "projet" disparaît en quelque sorte. Qui auraient tendance à désigner un dépôt comme principal/central.
ce que j'aime le plus à propos de Git est L'option Push/Pull, où vous pouvez facilement contribuer code à un projet sans avoir besoin d'avoir des droits d'engagement. Je suppose que vous pourriez utiliser des utilisateurs et des shelvesets très limités dans TFS pour imiter ceci, mais ce n'est pas aussi puissant que l'option Git. L'établissement de liens entre les projets d'équipe peut aussi bien 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 généraux.
je voudrais aussi 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, la production 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. Ceux - ci deviennent beaucoup plus difficiles lorsque vous utilisez un modèle distribué pur, à moins que vous ne fassiez conduire un des noeuds (et donc revenir à un modèle moins distribué).
avec TFS Basic venant avec TFS 11, Il pourrait être pas loin d'attendre un TFS distribué qui vous permet de synchroniser votre TFS local de base à un TFS central dans L'ère TFS 12+. Je vais mettre mon voter pour ça dans le uservoice !
pour moi la différence majeure est 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 se terminant par la mauvaise branche, ce qui a conduit à un débogage intéressant...