Git vs Team Foundation Server [fermé]


263

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?


24
Vous faites face à une bataille difficile sur celui-ci. Git est loin d'être aussi mature que svn / hg / tfs sous Windows, ce qui ne dérange pas beaucoup les vétérans de git, mais c'est un casse-tête majeur pour les nouveaux arrivants.
Marcelo Cantos

7
@Jacko: J'ai évalué git-for-Windows au cours des dernières semaines. Bien qu'il se soit nettement amélioré depuis la dernière fois que je l'ai examiné il y a environ un an, il est encore loin d'être prêt pour les heures de grande écoute avec les développeurs Windows typiques. Par exemple, le plugin VS est franchement affligeant. Ce n'est rien d'autre qu'un tas d'options de menu sous la barre de menu principale, qui échouent silencieusement si la solution est sélectionnée au lieu d'un projet. Je ne peux pas obtenir l'outil de validation pour indexer les segments et les lignes, ce qui est la principale raison pour laquelle j'utilise git, et arriver à git gui (qui est une atrocité complète, à partir d'un POV d'utilisation) est au mieux maladroit.
Marcelo Cantos

6
Je serai honnête avec vous, cependant; ça me tue de laisser tomber git. Contrairement à l'opinion répandue selon laquelle les deux sont à égalité, je trouve que le modèle de git est beaucoup plus puissant et logique. Mercurial n'a rien à voir avec l'indice de git, et je déteste son approche de la ramification. Le concept de Git d'étiquettes que vous déplacez et synchronisez entre les référentiels est très élégant. Les signets de Mercurial sont la seule chose qui se rapproche et ils sont un PITA à configurer pour tout le monde. L'essentiel, cependant, est que le succès est plus probable avec svn → Mercurial qu'avec svn → git, étant donné le personnel et la maturité relative des outils.
Marcelo Cantos

4
oui, Git règne en matière de puissance et d'élégance. Mais tout le monde n'y est pas prêt.
Jacko

7
@JamesReategui: Je pense personnellement ( stackoverflow.com/a/11362998/520162 ) que l'intégration d'un VCS dans un IDE est un méandre. Imaginez si vous changez votre IDE principal demain. Et si vous supprimez VS pour Eclipse? Êtes-vous vraiment prêt à apprendre une nouvelle intégration VCS? Git est génial sur la ligne de commande ( stackoverflow.com/a/5645910/520162 ). Apprenez-le et vous découvrirez un monde incroyablement puissant de contrôle de version.
vérifie le

Réponses:


273

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 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 ):

  • sauvegarde automatique de l'ensemble du référentiel: chaque fois que quelqu'un se retire du référentiel central, il / elle obtient un historique complet des modifications. Lorsqu'un dépôt est perdu: ne vous inquiétez pas, prenez un de ceux présents sur chaque poste de travail.
  • Accès repo en ligne: quand je travaille à la maison (ou dans un avion ou train), je peux voir l'histoire complète du projet, chaque checkin, sans démarrer ma connexion VPN au travail et peut travailler comme j'étais au travail : arrivée, départ, succursale, quoi que ce soit.

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.


22
Frappez, eckes. Ils me blâment chaque fois que quelque chose se passe mal. Pas eux-mêmes pour ne pas avoir appris comment cela fonctionne. Pour moi, Git est aussi proche de la perfection que je n'ai jamais connu dans un système de contrôle de version.
Jacko

15
D'autre part, TFS comprend le suivi des défauts / éléments de travail, les rapports, ... et d'autres fonctions. Donc, Git vs TFS sur VCS ne manque que le point de TFS.
Richard

5
@Dan voir rebase, filtre-arbre ...
Artefacto

7
@Artefacto Je sais, mais toutes les balises de validation changent et toutes les métadonnées (discussions sur la révision du code, etc.) sont orphelines ou doivent être mises à jour. Néanmoins, un mois avec TFS m'a convaincu qu'il n'est pas dans la ligue de Git en tant que système de contrôle de version. Git libère le développeur pour être productif d'une manière qui doit être expérimentée pour être comprise. La branche comme métaphore du bloc-notes est méchante et puissante.
Dan Solovay

6
@ Richard Je dirais que c'est un inconvénient de TFS: une fois que vous êtes dedans, vous êtes tous dedans. Il fait tout ce qui est médiocre et ne vous donne pas le choix. Il existe de bien meilleurs outils pour suivre les éléments de travail, les rapports et la gestion de projet.
Ben Collins

102

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).


5
Si vous songez à utiliser Mercurial, Joel Spolsky a un excellent site de tutoriel pour éduquer votre équipe: hginit.com
Martin Owen

3
Il pourrait être utile de mentionner que git est parfaitement capabable de l' émulation d' un système centralisé et commun est tout d'avoir un serveur git primaire pour tous les utilisateurs, vous suffit de ne pas avoir à le faire de cette façon.
Tim Abell

7
si vous travaillez sur une fonctionnalité qui pourrait casser d'autres choses - ne pourriez-vous pas simplement créer une branche dans TFS? Bien sûr - la succursale est sur un serveur central - mais est-ce vraiment important? Il semble que vous puissiez effectivement faire la même chose dans les deux - il semble plus question de savoir quel IDE vous utilisez et à quel point le système de contrôle de version est bien intégré avec lui -
William

13
Si vous travaillez sur une grande fonctionnalité qui pourrait potentiellement interrompre l'équipe, il est recommandé d'utiliser une branche de fonctionnalité, puis lorsqu'elle est prête, fusionnez dans la branche de développement.
Mike Cheel

9
@MikeCheel C'est un excellent commentaire. Vous pouvez également créer un Shelve de votre code tous les jours et les supprimer lorsque vous enregistrez enfin votre fonctionnalité (mais l'idée de branchement est une meilleure façon de le faire)
RPDeshaies

86

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.


3
Merci, Charlie. Je le sais, et vous le savez, mais il est difficile de communiquer avec des gens qui disent que "l'intégration du contrôle de code source avec Visual Studio est la fonctionnalité la plus importante pour moi"
Jacko

58
Je connais. Un ami et moi jetions cette analogie - imaginez que vous avez besoin d'une base de données relationnelle sérieuse. Vous évaluez Sql Server, Oracle et MS Access. Vous finissez par choisir Access car il possède la meilleure interface graphique, malgré le fait qu'il ne peut pas évoluer, n'impose pas très bien l'intégrité référentielle, etc. La ramification et la fusion sont la viande et les pommes de terre absolues d'un système de contrôle de version. Toute autre fonctionnalité est juste un peu bling sur le côté. Mais les gens font des choix basés sur le bling.
Charlie Flowers

17
Bien que j'aie tendance à être d'accord avec vos déclarations, je ne vois pas pourquoi la ramification et la fusion de Git est "meilleure" simplement parce que c'est un système "distribué". Je ne suis pas sûr qu'être un DVCS ait quelque chose à voir avec sa capacité à fusionner. J'aimerais une explication des raisons pour lesquelles la fusion est plus facile dans un système distribué. D'après mon expérience, qui est principalement Git et Svn, la fusion dans SVN est terrible non pas parce qu'il s'agit d'un VCS centralisé, mais parce qu'il ne suit pas correctement les révisions entre les branches comme le fait GIT.
CodingWithSpike

8
@ rally25rs - Je suis d'accord avec la plupart de cela. Il n'y a aucune raison qu'un VCS ne puisse pas être bon aussi pour la fusion. Il n'y en a tout simplement pas (à ma connaissance). Mais la partie avec laquelle je ne suis pas d'accord est "purement en écrivant de meilleures routines de fusion qui résolvent mieux les conflits". La sauce secrète ne réside pas dans des routines de fusion plus intelligentes, mais dans une approche fondamentalement différente des informations que vous stockez dans le référentiel et de la façon dont vous les organisez. Principalement, faire des Commits le fondement de l'État interne. Les engagements ne sont pas seulement un boulon cool ... ils sont le fondement des capacités.
Charlie Flowers

10
@ rally25rs est tout à fait d'accord sur re: s'engage à être l'unité atomique de travail. Non seulement la plupart des systèmes centralisés n'organisent pas les données de cette façon, mais ils découragent le type de travail instantané que les développeurs doivent effectuer afin de faire un très bon travail de branchement et de fusion. Les systèmes distribués encouragent ce que j'appelle des commits «appropriés» (autonomes, petits commits de travaux pertinents avec de bonnes descriptions) et les systèmes centralisés encouragent ce que j'appelle des «bombes diff» où vous vous enfoncez dans une grotte jusqu'à ce que vous soyez prêt, puis vous laissez tomber des jours (ou semaines) de travail sur le système. Devinez quel type fusionne le mieux?
Ben Collins

45

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.


2
Cela répond à la question, ce ne devrait pas être un commentaire, même si vous aviez le représentant.
SingleNegationElimination

8
FYI - TFS "11" ne nécessite plus le bit en lecture seule si vous utilisez des espaces de travail locaux qui est la valeur par défaut maintenant. Il découvre intelligemment quels fichiers sont modifiés à partir de n'importe quelle application. Brian Harry a plus d'informations sur les améliorations ici: blogs.msdn.com/b/bharry/archive/2011/08/02/…
Ed Blankenship

2
@EdBlankenship, merci beaucoup pour ce lien de blog. C'est une excellente nouvelle de voir que le non-sens des bits en lecture seule est traité pour faciliter l'utilisation de la prochaine version de TFS.
Lee Grissom

7
Contrairement aux commits dans une branche comme vous le faites avec Git, les étagères ne sont pas faciles à comprendre et à gérer. Vous ne savez pas à chaque commit que le rayonnage a été fait et vous avez souvent des problèmes de fusion (si vous avez depuis apporté des modifications, elles sont souvent perdues). La branche Git est beaucoup plus puissante et compréhensible que les étagères. Le rayonnage est destiné aux développeurs qui n'ont jamais vécu autre chose ....
Philippe

2
Ce flux de travail consistant à «extraire» un fichier rappelle Visual SourceSafe, car c'était la façon habituelle de travailler; les fichiers ont été récupérés à partir de SourceSafe et stockés localement en tant que fichiers en lecture seule. La récupération d'un fichier ou d'un groupe de fichiers peut être marquée comme exclusive, ce qui signifie que d'autres pourraient voir l'ensemble de fichiers sur lequel un autre développeur travaille, afin d'éviter la nécessité de fusionner lorsque la branche a été désactivée (probablement en raison d'être un cochon droit dans VSS).
Brett Rigby

18

En plus de tout ce qui a été dit (

https://stackoverflow.com/a/4416666/172109

https://stackoverflow.com/a/4894099/172109

https://stackoverflow.com/a/4415234/172109

), 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 moyenne des 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.


4
S'il vous plaît, vous pouvez obtenir les mêmes outils que TFS fournit dans n'importe quelle application d'outil agile. Rallye, vous l'appelez.
PositiveGuy

2
Bien que je sois d'accord sur le fait que TFS a un objectif plus large, je le reformulerais "il ESSAYE de fournir une destination unique", mais ce n'est pas assez bon (du moins pas la meilleure option) dans aucune des tâches qu'il essaie de résoudre; c'est comme un couteau suisse émoussé.
slashCoder

@PositiveGuy vous ne pouvez pas l'obtenir sans travail et configuration. TFS vous donne le tout en un clic. À titre d'exemple, l'ensemble de l'écosystème est désormais disponible en tant que service cloud, sans aucune configuration requise. Si je peux obtenir le contrôle de version, le support Scrum, les builds automatisés, le laboratoire de test et la gestion du plan de test, tous intégrés dès le départ avec eux-mêmes ET un LDAP d'entreprise (lie AzureAD), pour 10 $ / mois, pourquoi irais-je dans mon bon sens essayer de coller des morceaux ensemble par moi-même?
Craig Brunetti

1
@slashCoder comment une suite complète pourrait-elle être la meilleure à chaque pièce? Est-ce que le coût de sa non-meilleure qualité l'emporte vraiment sur le coût de la gestion de l'intégration des composants par vous-même? ... peut-être pour certains endroits, je peux le voir. Mais c'est de la pure surcharge d'avoir à exécuter de telles choses. Que se passe-t-il si votre GIT d'entreprise fonctionne correctement, mais que votre instance JIRA tombe en panne et que votre mise à niveau Jenkins ne fonctionne pas? Droite? C'est comme jongler avec des tronçonneuses. Sur le feu. Les yeux bandés. :) :)
Craig Brunetti

17

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


6
Microsoft fournit une intégration directe avec les référentiels Git et TFS maintenant: blogs.msdn.com/b/bharry/archive/2012/08/13/…
Ed Blankenship

1
@EdBlankenship, vous souhaiterez peut-être convertir votre commentaire en réponse. Cela semble être une excellente solution pour le PO. Je voterai pour. :)
Lee Grissom

1
Sauf si vous êtes sur une autre plateforme que Windows, vous devriez préférer git-tfs! git-tf est loin d'être aussi bon que git-tfs ... Et la philosophie est orientée TFS alors que git-tfs est plus orienté git (et c'est ce que nous voulons!)
Philippe

15

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 .


3
Peut-être, mais chaque partie de TFS est mauvaise et difficile à administrer (en fait, vous avez besoin d'un véritable administrateur pour TFS). Regardez Git> TFS (VCS), Jenkins> TFS (CI), nunit ou xunit> mstest, IceScrum ou ...> TFS (Project Management). TFS est une bonne idée au début, jusqu'à ce que vous l'utilisiez !!!
Philippe

1
pourquoi avez-vous besoin de TFS, obtenez simplement une bonne application agile. Et puis utilisez Git ou subversion et vous êtes sur la bonne voie. TFS se met juste sur votre chemin en vous enlisant avec des problèmes.
PositiveGuy

Mise à jour: TFS 2013 (serveur) [et VS12-13) prend désormais en charge git pour le contrôle de version. Vous pouvez donc tirer le meilleur
parti

2
Bien sûr, c'est bien d'avoir un ALM entièrement intégré. Mais pas au détriment de la flexibilité. OMI. un ALM doit être construit avec autant de technologie "best of race" que possible ... ou à tout le moins, la flexibilité d'intégrer le meilleur des races, car elles sont susceptibles de changer avec le temps. Choisir TFS, c'est fondamentalement mettre un enjeu dans le sol, en disant que "microsoft va gagner à tous les aspects de mon ALM", ce qui est idiot. J'ai utilisé Git w / Jira, par exemple, ce qui m'a permis de mettre à jour / fermer les problèmes en fonction de mon message de validation. D'après mon expérience (beaucoup avec TFS aussi), c'est un flux de travail largement supérieur.
Scott Silvi

1
Barre latérale - même avec l'intégration TFS / Git, vous dites essentiellement "permet de distribuer VCS à Git, tout en gardant notre suivi des problèmes" - fondamentalement pas différent de l'utilisation de Git avec tout autre logiciel de suivi des problèmes. Je ne suis donc pas sûr que l'argument ALM soit plus valide, étant donné les tentatives de flexibilité de Microsofts (que j'applaudis).
Scott Silvi

14

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 !


Vous serez également intéressé par cette nouvelle fonctionnalité proposée par Microsoft: gittf.codeplex.com
jessehouwing

1
utilisez git-tfs. Pour le moment, c'est bien mieux que git-tf !!! github.com/git-tfs/git-tfs
Philippe

3
Toute cette réponse devient rapidement obsolète. Microsoft a ajouté la prise en charge de Git à Team Foundation Service et ajoutera la prise en charge de Git à la prochaine version majeure de Team Foundation Server.
jessehouwing

1
@Philippe: J'ai essayé les deux. Quelques différences: 1) git-tf est multi-plateforme, alors que git-tfs ne fonctionne que sur Windows. 2) git-tfs réécrit les descriptions de validation lorsque vous "poussez" pour inclure le numéro de l'ensemble de modifications, tandis que git-tf laisse vos hachages de validation locaux intacts.
Joey Adams

@JoeyAdams 1) +1, c'est la seule bonne raison de choisir git-tf 2) Vous pouvez également le faire avec git-tfs en utilisant la 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;)
Philippe

9

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 ...


2
Bon point ici. Git ajoutera le .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.
CodingWithSpike

5
J'avais oublié combien je détestais la façon dont VSS modifierait vos fichiers «pour» vous.
Paddy
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.