Git vs Team Foundation Server [geschlossen]

262

Ich habe Git meinem Entwicklerteam vorgestellt und alle außer mir hassen es. Sie möchten es durch Team Foundation Server ersetzen. Ich denke, dies ist ein großer Rückschritt, obwohl ich mit TFS nicht sehr vertraut bin. Kann jemand mit Erfahrung die Verzweigungsunterstützung für TFS mit der Git-Verzweigung vergleichen? Welche Vor- und Nachteile hat TFS im Allgemeinen? Werde ich es hassen, nachdem ich Git ein paar Jahre lang benutzt habe?

git tfs tfvc

— Jacko
quelle

24

Sie stehen vor einem harten Kampf. Git ist bei weitem nicht so ausgereift wie svn / hg / tfs unter Windows, was Git-Veteranen nicht sonderlich stört, aber Neulingen große Kopfschmerzen bereitet.

— Marcelo Cantos

7

@ Jacko: Ich habe Git-for-Windows in den letzten Wochen evaluiert. Obwohl es sich seit meinem letzten Blick vor etwa einem Jahr deutlich verbessert hat, ist es noch weit davon entfernt, mit typischen Windows-Entwicklern für die Hauptsendezeit bereit zu sein. ZB ist das VS-Plugin ehrlich gesagt traurig. Es ist nichts anderes als eine Reihe von Menüoptionen unter der Hauptmenüleiste, die stillschweigend fehlschlagen, wenn die Lösung anstelle eines Projekts ausgewählt wird. Ich kann das Commit-Tool nicht dazu bringen, Hunks und Linien zu indizieren, was der Hauptgrund ist, warum ich git verwende, und es ist bestenfalls umständlich, zu git gui zu gelangen (was eine völlige Gräueltat aus einem Usability-POV ist).

— Marcelo Cantos

6

Ich werde jedoch ehrlich zu dir sein; es bringt mich um, git fallen zu lassen. Entgegen der weit verbreiteten Ansicht, dass die beiden gleichwertig sind, finde ich das Modell von git viel leistungsfähiger und logischer. Mercurial hat nichts mit dem Index von git zu tun, und ich hasse seinen Ansatz zur Verzweigung. Gits Konzept von Labels, die Sie verschieben und zwischen Repos synchronisieren, ist sehr elegant. Die Lesezeichen von Mercurial sind das einzige, was nahe kommt, und sie sind eine PITA, die für alle eingerichtet werden kann. Das Fazit ist jedoch, dass Erfolg mit svn → Mercurial wahrscheinlicher ist als mit svn → git, angesichts des Personals und der relativen Reife der Tools.

— Marcelo Cantos

4

Ja, Git regiert, wenn es um Kraft und Eleganz geht. Aber nicht jeder ist dazu bereit.

— Jacko

7

@ JamesReategui: Ich persönlich denke ( stackoverflow.com/a/11362998/520162 ), dass die Integration eines VCS in eine IDE ein Mäander ist. Stellen Sie sich vor, Sie wechseln morgen Ihre Haupt-IDE. Was ist, wenn Sie VS für Eclipse löschen? Sind Sie wirklich bereit, eine neue VCS-Integration zu lernen? Git ist großartig in der Kommandozeile ( stackoverflow.com/a/5645910/520162 ). Lernen Sie es und entdecken Sie eine unglaublich leistungsstarke Welt der Versionskontrolle.

— eckes

272

Ich denke, die Aussage

Alle außer mir hassen es

Weitere Diskussionen werden verschwendet: Wenn Sie weiterhin Git verwenden, werden Sie beschuldigt , wenn etwas schief geht.

Abgesehen davon hat Git für mich zwei Vorteile gegenüber einem zentralisierten VCS, die ich am meisten schätze (wie teilweise von Rob Sobers beschrieben ):

Automatische Sicherung des gesamten Repos : Jedes Mal, wenn jemand aus dem zentralen Repo zieht, erhält er eine vollständige Historie der Änderungen. Wenn ein Repo verloren geht: Keine Sorge, nehmen Sie eines der auf jeder Workstation vorhandenen mit.
offline Repo - Zugang: wenn ich zu Hause bin arbeiten (oder in einem Flugzeug oder Zug), kann ich die vollständige Geschichte des Projekts sehen, jedes einzelne checkin, ohne meine VPN - Verbindung zu Beginn der Arbeiten und arbeiten kann , wie ich waren bei der Arbeit : Einchecken, Auschecken, Filiale, alles.

Aber wie gesagt: Ich denke, du kämpfst einen verlorenen Kampf: Wenn jeder Git hasst, benutze Git nicht. Es könnte dir mehr helfen zu wissen, warum sie Git hassen, anstatt zu versuchen, sie zu überzeugen.

Wenn sie es einfach nicht wollen, weil es für sie neu ist und nicht bereit ist, etwas Neues zu lernen: Sind Sie sicher, dass Sie mit diesen Mitarbeitern eine erfolgreiche Entwicklung durchführen werden?

Hasst wirklich jeder einzelne Git oder werden sie von einigen Meinungsführern beeinflusst? Finden Sie die Führer und fragen Sie sie, was das Problem ist. Überzeugen Sie sie und Sie werden den Rest des Teams überzeugen.

Wenn Sie die Führungskräfte nicht überzeugen können: Vergessen Sie die Verwendung von Git, nehmen Sie das TFS. Erleichtert Ihnen das Leben.

— eckes
quelle

22

Knall an, eckes. Sie beschuldigen mich, wenn etwas schief geht. Nicht sie selbst, weil sie nicht gelernt haben, wie es funktioniert. Für mich ist Git so perfekt, wie ich es noch nie in einem Versionskontrollsystem erlebt habe.

— Jacko

15

Zum anderen umfasst TFS die Verfolgung von Fehlern / Arbeitselementen, Berichte usw. und andere Funktionen. Daher fehlt Git vs TFS nur bei der VCS-Funktionalität eher der Sinn von TFS.

— Richard

5

@ Dan sehen Rebase, Filter-Baum ...

— Artefacto

7

@Artefacto Ich weiß, aber dann ändern sich alle Commit-Tags und alle Metadaten (Codeüberprüfungsdiskussionen usw.) sind verwaist oder müssen aktualisiert werden. Trotzdem hat mich ein Monat mit TFS davon überzeugt, dass es als Versionskontrollsystem nicht in Gits Liga ist. Git gibt dem Entwickler die Freiheit, auf eine Weise produktiv zu sein, die erlebt werden muss, um verstanden zu werden. Der Zweig als Notizblock-Metapher ist böse mächtig.

— Dan Solovay

6

@Richard Ich würde behaupten, dass dies ein Nachteil von TFS ist: Wenn Sie einmal dabei sind, sind Sie alle dabei. Es macht alles mittelmäßig und gibt Ihnen keine Wahl. Es gibt weitaus bessere Tools zum Verfolgen von Arbeitselementen, Berichten und zum Projektmanagement.

— Ben Collins

102

Der Hauptunterschied zwischen den beiden Systemen besteht darin, dass TFS ein zentrales Versionskontrollsystem und Git ein verteiltes Versionskontrollsystem ist.

Mit TFS werden Repositorys auf einem zentralen Server gespeichert, und Entwickler checken eine Arbeitskopie aus, die eine Momentaufnahme des Codes zu einem bestimmten Zeitpunkt ist. Mit Git klonen Entwickler das gesamte Repository auf ihre Computer, einschließlich des gesamten Verlaufs.

Ein Vorteil des vollständigen Repositorys auf den Computern Ihres Entwicklers ist die Redundanz für den Fall, dass der Server ausfällt. Ein weiterer Vorteil ist, dass Sie Ihre Arbeitskopie zwischen den Revisionen hin und her verschieben können, ohne jemals mit dem Server zu sprechen. Dies kann hilfreich sein, wenn der Server ausfällt oder nur nicht erreichbar ist.

Für mich ist der wahre Segen , dass Sie verpflichten Changesets auf Ihrem lokalen Repository , ohne jemals im Gespräch mit dem Server oder zuzufügen potenziell instabilen Änderungen in Ihrem Team (dh brechen die Build).

Wenn ich beispielsweise an einem großen Feature arbeite, kann es eine Woche dauern, bis ich es vollständig codiert und getestet habe. Ich möchte nicht Mitte der Woche instabilen Code einchecken und den Build abbrechen, aber was passiert, wenn ich mich dem Ende der Woche nähere und versehentlich meine gesamte Arbeitskopie borke? Wenn ich mich nicht die ganze Zeit engagiert habe, besteht das Risiko, dass ich meine Arbeit verliere. Dies ist keine effektive Versionskontrolle, und TFS ist dafür anfällig.

Mit DVCS kann ich ständig Commits durchführen, ohne mir Gedanken über das Brechen des Builds machen zu müssen, da ich meine Änderungen lokal festschreibe . In TFS und anderen zentralisierten Systemen gibt es kein Konzept für ein lokales Einchecken.

Ich habe noch nicht einmal untersucht, wie viel besser das Verzweigen und Zusammenführen in DVCS ist, aber Sie können hier auf SO oder über Google unzählige Erklärungen finden. Ich kann Ihnen aus Erfahrung sagen, dass das Verzweigen und Zusammenführen in TFS nicht gut ist.

Wenn das Argument für TFS in Ihrer Organisation lautet, dass es unter Windows besser funktioniert als Git, würde ich Mercurial vorschlagen, das unter Windows hervorragend funktioniert - es gibt eine Integration mit Windows Explorer (TortoiseHg) und Visual Studio (VisualHg).

— Rob Sobers
quelle

5

Wenn Sie überlegen, mit Mercurial zu arbeiten, hat Joel Spolsky eine ausgezeichnete Tutorial-Site für die Ausbildung Ihres Teams: hginit.com

— Martin Owen

3

Es könnte erwähnenswert sein, dass Git perfekt in der Lage ist, ein zentrales System zu emulieren, und es ist üblich, einen primären Git-Server für alle Benutzer zu haben. Sie müssen dies einfach nicht so tun.

— Tim Abell

7

Wenn Sie an einer Funktionalität arbeiten, die andere Probleme verursachen könnte, können Sie dann nicht einfach einen Zweig in TFS erstellen? Sicher - der Zweig befindet sich auf einem zentralen Server - aber ist das wirklich wichtig? Es scheint, als könnten Sie in beiden

— William

13

Wenn Sie an einem großen Feature arbeiten, das das Team möglicherweise unterbrechen könnte, wird empfohlen, einen Feature-Zweig zu verwenden und dann, wenn Sie bereit sind, in den Entwicklungszweig zu integrieren.

— Mike Cheel

9

@ MikeCheel Dies ist ein großartiger Kommentar. Sie können auch jeden Tag ein Regal Ihres Codes erstellen und diese löschen, wenn Sie Ihre Funktion endgültig einchecken (aber die Verzweigungsidee ist ein besserer Weg, dies zu tun)

— RPDeshaies

86

Die Leute müssen die Waffe niederlegen, sich von der Kante entfernen und eine Minute nachdenken . Es stellt sich heraus, dass DVCS objektive, konkrete und unbestreitbare Vorteile bietet, die einen RIESIGEN Unterschied in der Produktivität eines Teams bewirken.

Es kommt alles auf das Verzweigen und Zusammenführen an.

Vor DVCS lautete das Leitprinzip: "Bete zu Gott, dass du dich nicht verzweigen und verschmelzen musst. Und wenn du das tust, bitte ihn zumindest, es sehr, sehr einfach sein zu lassen."

Mit DVCS wird das Verzweigen ( und Zusammenführen ) so stark verbessert, dass das Leitprinzip lautet: "Machen Sie es im Handumdrehen. Es bietet Ihnen eine Menge Vorteile und verursacht Ihnen keine Probleme."

Und das ist ein RIESIGER Produktivitätsschub für jedes Team.

Das Problem ist, dass die Leute, um zu verstehen, was ich gerade gesagt habe, und davon überzeugt sind, dass es wahr ist, zuerst in eine kleine Lernkurve investieren müssen. Sie müssen weder Git noch irgendein anderes DVCS selbst lernen ... sie müssen nur lernen, wie Git verzweigt und zusammenführt. Lesen und lesen Sie einige Artikel und Blog-Beiträge erneut, nehmen Sie sie langsam und arbeiten Sie sie durch, bis Sie sie sehen. Das kann fast zwei oder drei volle Tage dauern.

Aber sobald Sie das sehen, werden Sie nicht einmal in Betracht ziehen, ein Nicht-DVCS zu wählen. Denn DVCS bietet wirklich klare, objektive und konkrete Vorteile, und die größten Gewinne liegen im Bereich der Verzweigung und Zusammenführung.

— Charlie Flowers
quelle

3

Danke, Charlie. Ich weiß es, und Sie wissen es, aber es ist schwierig, Leute zu erreichen, die Dinge wie "Die Integration der Quellcodeverwaltung in Visual Studio ist das wichtigste Feature für mich" sagen

— Jacko

58

Ich weiß. Ein Freund und ich haben diese Analogie herumgeworfen - stellen Sie sich vor, Sie brauchen eine ernsthafte relationale Datenbank. Sie bewerten SQL Server, Oracle und MS Access. Am Ende entscheiden Sie sich für Access, weil es die schönste Benutzeroberfläche hat, obwohl es nicht skalierbar ist, die referenzielle Integrität nicht sehr gut erzwingt usw. Verzweigen und Zusammenführen sind das absolute Fleisch und die Kartoffeln eines Versionskontrollsystems. Jedes andere Merkmal ist nur ein wenig bling auf der Seite. Aber die Leute treffen Entscheidungen basierend auf dem Bling.

— Charlie Flowers

17

Obwohl ich Ihren Aussagen eher zustimme, verstehe ich nicht, warum das Verzweigen und Zusammenführen von Git "besser" ist, nur weil es ein "verteiltes" System ist. Ich bin mir nicht sicher, ob ein DVCS etwas mit seiner Fähigkeit zum Zusammenführen zu tun hat. Ich würde gerne erklären, warum das Zusammenführen in einem verteilten System einfacher ist. Nach meiner Erfahrung, bei der es sich hauptsächlich um Git und Svn handelt, ist das Zusammenführen in SVN nicht deshalb schrecklich, weil es sich um ein zentrales VCS handelt, sondern weil es Revisionen über Zweige hinweg nicht richtig verfolgt, wie es GIT tut.

— CodingWithSpike

8

@ Rally25rs - Ich stimme dem größten Teil zu. Es gibt keinen Grund, warum ein VCS nicht gut zusammengeführt werden kann. Es gibt einfach noch keine (von denen ich weiß). Aber der Teil, mit dem ich nicht einverstanden bin, ist "nur durch das Schreiben besserer Zusammenführungsroutinen, die Konflikte besser lösen". Die geheime Sauce besteht nicht aus intelligenteren Zusammenführungsroutinen, sondern aus einem grundlegend anderen Ansatz, welche Informationen Sie im Repo speichern und wie Sie sie organisieren. Hauptsächlich Commits zur Grundlage des internen Staates machen. Commits sind nicht nur ein cooler Bolt-On ... sie sind die Grundlage für die Fähigkeiten.

— Charlie Flowers

10

@ Rally25rs stimmen voll und ganz zu re: verpflichtet sich, die atomare Arbeitseinheit zu sein. Die meisten zentralisierten Systeme organisieren die Daten nicht nur nicht auf diese Weise, sondern entmutigen auch die momentane Arbeit, die die Entwickler leisten müssen, um wirklich gute Branch-and-Merge-Arbeit zu leisten. Verteilte Systeme fördern das, was ich als "passende" Commits bezeichne (in sich geschlossene, kleine Commits relevanter Arbeit mit guten Beschreibungen), und zentralisierte Systeme fördern das, was ich "Diff-Bomben" nenne, bei denen Sie sich in einer Höhle aufhalten, bis Sie bereit sind und dann Tage fallen lassen (oder Wochen) Arbeit am System wert. Ratet mal, welche Art am besten verschmilzt?

— Ben Collins

45

Original : @Rob, TFS hat etwas namens " Shelving ", das Ihre Bedenken hinsichtlich der Festlegung laufender Arbeiten aufgreift, ohne dass dies Auswirkungen auf den offiziellen Build hat. Mir ist klar, dass Sie die zentrale Versionskontrolle als Hindernis ansehen, aber in Bezug auf TFS kann das Einchecken Ihres Codes in das Regal als Stärke angesehen werden. In seltenen Fällen verfügt der zentrale Server über eine Kopie Ihrer laufenden Arbeiten Ihre lokale Maschine stürzt ab oder geht verloren / wird gestohlen oder Sie müssen schnell umschalten. Mein Punkt ist, dass TFS in diesem Bereich angemessen gelobt werden sollte. Außerdem wurde das Verzweigen und Zusammenführen in TFS2010 gegenüber früheren Versionen verbessert, und es ist nicht klar, auf welche Version Sie sich beziehen, wenn Sie sagen "... aus Erfahrung, dass das Verzweigen und Zusammenführen in TFS nicht gut ist". Haftungsausschluss: Ich bin ein moderater Benutzer von TFS2010.

Edit Dec-5-2011 : Für das OP ist eine Sache, die mich an TFS stört, dass es darauf besteht, alle Ihre lokalen Dateien auf "schreibgeschützt" zu setzen, wenn Sie nicht daran arbeiten. Wenn Sie eine Änderung vornehmen möchten, müssen Sie die Datei "auschecken", wodurch nur das schreibgeschützte Attribut in der Datei gelöscht wird, damit TFS ein Auge darauf hat. Das ist ein unpraktischer Workflow. Ich würde es vorziehen, wenn es funktioniert. Es erkennt nur automatisch, ob ich eine Änderung vorgenommen habe, und kümmert sich überhaupt nicht um die Dateiattribute. Auf diese Weise kann ich die Datei entweder in Visual Studio oder Notepad oder mit einem beliebigen Tool ändern. Das Versionskontrollsystem sollte diesbezüglich so transparent wie möglich sein. Es gibt eine Windows Explorer-Erweiterung ( TFS PowerTools)), mit dem Sie im Windows Explorer mit Ihren Dateien arbeiten können, der den Workflow jedoch nicht wesentlich vereinfacht.

— Lee Grissom
quelle

2

Dies beantwortet die Frage, es sollte kein Kommentar sein, selbst wenn Sie den Repräsentanten hatten.

— SingleNegationElimination

8

Zu Ihrer Information - TFS "11" benötigt kein schreibgeschütztes Bit mehr, wenn Sie lokale Arbeitsbereiche verwenden, was jetzt die Standardeinstellung ist. Es erkennt auf intelligente Weise, welche Dateien von einer Anwendung geändert werden. Brian Harry hat einige weitere Informationen zu den Verbesserungen hier: blogs.msdn.com/b/bharry/archive/2011/08/02/…

— Ed Blankenship

2

@EdBlankenship, vielen Dank für diesen Blog-Link. Das sind hervorragende Neuigkeiten, um zu sehen, dass der schreibgeschützte Bit-Unsinn behoben wird, um die Verwendung der nächsten Version von TFS erheblich zu vereinfachen.

— Lee Grissom

7

Im Gegensatz zu Commits in einem Zweig wie bei Git ist das Regal nicht einfach zu verstehen und zu verwalten. Sie wissen nicht bei jedem Commit, dass das Regal erstellt wurde, und Sie haben häufig Probleme beim Zusammenführen (wenn Sie seitdem Änderungen vorgenommen haben, gehen diese häufig verloren). Git-Zweige sind viel leistungsfähiger und verständlicher als Regale. Regale sind für Entwickler, die noch nie etwas anderes erlebt haben ...

— Philippe

2

Dieser Workflow zum Auschecken einer Datei erinnert an Visual SourceSafe, da dies die übliche Arbeitsweise war. Dateien wurden aus SourceSafe abgerufen und lokal als schreibgeschützte Dateien gespeichert. Das Auschecken einer Datei oder einer Reihe von Dateien kann als exklusiv markiert werden, was bedeutet, dass andere die Dateigruppe sehen können, an der ein anderer Entwickler arbeitet, um zu verhindern, dass beim Deaktivieren der Verzweigung eine Zusammenführung erforderlich ist (wahrscheinlich aufgrund einer rechtes Schwein in VSS).

— Brett Rigby

18

Zu allem, was gesagt wurde (

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

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

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

), was richtig ist, TFS ist nicht nur ein VCS. Eine wichtige Funktion von TFS ist die nativ integrierte Fehlerverfolgungsfunktion. Änderungssätze sind mit Problemen verknüpft und können nachverfolgt werden. Es werden verschiedene Richtlinien für das Einchecken sowie die Integration in die Windows-Domäne unterstützt, über die Benutzer von TFS verfügen. Eine eng integrierte Benutzeroberfläche in Visual Studio ist ein weiteres Verkaufsargument, das ~~weniger als den durchschnittlichen~~ Maus- und Klickentwickler und seinen Manager anspricht .

Daher ist der Vergleich von Git mit TFS keine richtige Frage. Die richtige, wenn auch unpraktische Frage ist, Git nur mit der VCS-Funktionalität von TFS zu vergleichen. Dabei bläst Git TFS aus dem Wasser. Jedes ernsthafte Team benötigt jedoch andere Tools, und hier bietet TFS ein One-Stop-Ziel.

— Sherlock
quelle

4

Bitte Sie können die gleichen Tools erhalten, die TFS in jeder agilen Tool-Anwendung bereitstellt. Rallye, du nennst es.

— PositiveGuy

2

Ich stimme zwar der Tatsache zu, dass TFS ein breiteres Ziel verfolgt, würde es aber in "es versucht, ein One-Stop-Ziel bereitzustellen" umformulieren, aber es ist bei keiner der Aufgaben, die es versucht, gut genug (zumindest nicht die beste Option) lösen; Es ist also wie ein stumpfes Schweizer Messer.

— SlashCoder

@ PositiveGuy Sie können es nicht ohne Arbeit und Konfiguration bekommen. TFS gibt Ihnen das Ganze mit einem Klick. In diesem Fall ist das gesamte Ökosystem jetzt als Cloud-Dienst verfügbar, ohne dass eine Konfiguration erforderlich ist. Wenn ich Versionskontrolle, Scrum-Unterstützung, automatisierte Builds, Testlabor und Testplanverwaltung erhalten kann, die alle für 10 US-Dollar pro Monat in sich integriert sind, und ein Unternehmens-LDAP (lie AzureAD), warum sollte ich dann bei klarem Verstand gehen? versuchen, Stücke selbst zusammenzufügen?

— Craig Brunetti

1

@slashCoder Wie kann man erwarten, dass eine vollständige Suite bei jedem Stück die beste ist? Wiegen die Kosten für die Nicht-Best-Ed-Ness wirklich die Kosten für die Verwaltung der Komponentenintegration auf eigene Faust auf? ... vielleicht kann ich das an einigen Orten sehen. Aber es ist purer Aufwand, solche Dinge ausführen zu müssen. Was passiert, wenn Ihr Unternehmens-GIT einwandfrei funktioniert, Ihre JIRA-Instanz jedoch ausfällt und Ihr Jenkins-Upgrade nicht funktioniert? Richtig? Es ist wie mit Kettensägen zu jonglieren. In Brand geraten. Halb mit verbundenen Augen. :) :)

— Craig Brunetti

17

Wenn Ihr Team TFS verwendet und Sie Git verwenden möchten, sollten Sie eine "Git to TFS" -Brücke in Betracht ziehen. Im Wesentlichen arbeiten Sie Tag für Tag mit Git auf Ihrem Computer. Wenn Sie Ihre Änderungen übertragen möchten, übertragen Sie sie auf den TFS-Server.

Es gibt ein paar da draußen (auf Github). Ich habe einen an meinem letzten Platz (zusammen mit einem anderen Entwickler) mit einigem Erfolg verwendet. Sehen:

https://github.com/spalts/git-tfs

https://github.com/git-tfs/git-tfs

— bytedev
quelle

6

Microsoft bietet jetzt eine direkte Integration mit Git-Repositorys und TFS: blogs.msdn.com/b/bharry/archive/2012/08/13/…

— Ed Blankenship

1

@EdBlankenship, möchten Sie möglicherweise Ihren Kommentar in eine Antwort konvertieren. Es scheint eine großartige Lösung für das OP zu sein. Ich werde dafür stimmen. :)

— Lee Grissom

1

Außer wenn Sie sich auf einer anderen Plattform als Windows befinden, sollten Sie git-tfs bevorzugen! git-tf ist bei weitem nicht so gut wie git-tfs ... Und die Philosophie ist TFS-orientiert, während git-tfs mehr git-orientiert ist (und das wollen wir!)

— Philippe

15

Nach einigen Nachforschungen zwischen Vor- und Nachteilen entschied sich das Unternehmen, an dem ich beteiligt war, auch für TFS. Nicht weil GIT kein gutes Versionskontrollsystem ist, sondern vor allem für die vollständig integrierte ALM-Lösung, die TFS liefert. Wenn nur die Versionskontrollfunktion wichtig war, könnte die Wahl wahrscheinlich GIT gewesen sein. Die steile GIT-Lernkurve für reguläre Entwickler darf jedoch nicht unterschätzt werden.

Eine ausführliche Erklärung finden Sie in meinem Blogbeitrag TFS als echte technologieübergreifende Plattform .

— Pieter Gheysens
quelle

3

Vielleicht, aber jeder Teil von TFS ist schlecht und schwer zu verwalten (tatsächlich benötigen Sie einen echten Administrator für TFS). Suchen Sie nach Git> TFS (VCS), Jenkins> TFS (CI), nunit oder xunit> mstest, IceScrum oder ...> TFS (Projektmanagement). TFS ist am Anfang eine gute Idee, bis Sie es verwenden !!!

— Philippe

1

Warum brauchen Sie TFS? Holen Sie sich einfach eine gute agile App. Und dann benutze Git oder Subversion und du bist auf dem Weg. TFS steht Ihnen nur im Weg, wenn Sie Probleme haben.

— PositiveGuy

Update: TFS 2013 (Server) [und VS12-13) unterstützt jetzt Git für die Versionskontrolle. So können Sie das Beste aus beiden Welten bekommen

— DarcyThomas

2

Klar, es ist schön, ein voll integriertes ALM zu haben. Aber nicht auf Kosten der Flexibilität. IMO. Ein ALM sollte mit so viel "Best-of-Breed" -Technologie wie möglich konstruiert werden ... oder zumindest mit der Flexibilität, die besten Rassen zu integrieren, da sie sich wahrscheinlich im Laufe der Zeit ändern werden. Wenn Sie sich für TFS entscheiden, setzen Sie im Grunde genommen eine Rolle in den Boden und sagen: "Microsoft wird in allen Aspekten meiner ALM gewinnen", was albern ist. Ich habe zum Beispiel Git mit Jira verwendet, wodurch ich Probleme basierend auf meiner Commit-Nachricht aktualisieren / schließen konnte. Nach meiner Erfahrung (auch mit TFS viel) ist dies ein weit überlegener Workflow.

— Scott Silvi

1

Seitenleiste - selbst mit der TFS / Git-Integration sagen Sie im Grunde genommen "Lässt VCS an Git ausliefern, während wir unsere Problemverfolgung beibehalten" - im Grunde nichts anderes als die Verwendung von Git mit einer anderen Problemverfolgungssoftware. Ich bin mir also nicht sicher, ob das ALM-Argument mehr gültig ist, da Microsoft versucht, flexibel zu sein (was ich begrüße).

— Scott Silvi

14

Die ganze Distributed-Sache von Git ist wirklich großartig. Es bietet einige Funktionen, über die Shelvesets (im aktuellen Produkt) nicht verfügen, z. B. lokale Rollback- und Commit-Optionen (z. B. die Localhistory-Funktion von Eclipse ). Sie könnten dies mit Entwicklerzweigen abmildern, aber seien wir ehrlich, viele Entwickler mögen es nicht, ein Bit zu verzweigen und zusammenzuführen. Ich wurde gebeten, die Funktion "Exklusives Auschecken" im alten Stil in TFS ein paar Mal zu oft zu aktivieren (und sie jedes Mal abzulehnen).

Ich denke, viele große Unternehmen haben große Angst davor, dass ein Entwickler einfach die gesamte Geschichte in einen lokalen Arbeitsbereich bringt und mitnimmt (zum Beispiel zu einem neuen Arbeitgeber) ... Einen Schnappschuss zu stehlen ist schlecht, aber eine ganze Geschichte wegzunehmen ist noch problematischer. (Nicht, dass Sie keine vollständige Historie von TFS erhalten könnten , von der Sie es wollten) ...

Es wird erwähnt, dass dies eine großartige Möglichkeit zum Sichern ist, was wiederum für Open Source großartig ist, wenn der ursprüngliche Betreuer möglicherweise aufhört, sich um seine Version zu kümmern und sie entfernt, aber für einen Unternehmensplan ist dies für viele Unternehmen wiederum unzureichend, da es keine eindeutige Zuweisung von Verantwortlichkeiten gibt Backups zu halten. Und es wäre schwer herauszufinden, welche Version verwendet werden soll, wenn das Hauptprojekt irgendwie verschwindet. Welches würde dazu neigen, ein Repository als führend / zentral zu ernennen.

Was mir an Git am besten gefällt, ist die Push / Pull-Option, mit der Sie problemlos Code zu einem Projekt beitragen können, ohne Commit-Rechte zu benötigen. Ich denke, Sie könnten sehr begrenzte Benutzer und Regale in TFS verwenden, um dies nachzuahmen, aber es ist nicht so leistungsfähig wie die Git-Option. Das Verzweigen über Teamprojekte hinweg mag ebenfalls funktionieren, aber aus administrativer Sicht ist dies für viele Unternehmen nicht wirklich machbar, da das Hinzufügen von Teamprojekten einen hohen Verwaltungsaufwand verursacht.

Ich möchte auch zu den Dingen hinzufügen, die im Bereich ohne Quellcodeverwaltung erwähnt werden. Funktionen wie Workitem-Tracking, Berichterstellung und Build-Automatisierung (einschließlich Laborverwaltung) profitieren in hohem Maße von einem zentralen führenden Repository. Diese werden viel schwieriger, wenn Sie ein rein verteiltes Modell verwenden, es sei denn, Sie machen einen der Knoten führend (und kehren daher zu einem weniger verteilten Modell zurück).

Da TFS Basic mit TFS 11 geliefert wird, ist es möglicherweise nicht weit entfernt, ein verteiltes TFS zu erwarten, mit dem Sie Ihr lokales TFS Basic in der TFS 12+ -Ära mit einem zentralen TFS synchronisieren können. Ich werde meine Stimme dafür im Uservoice ablegen !

— jessehouwing
quelle

Sie werden auch an dieser neuen Funktion interessiert sein, die Ihnen Microsoft zur Verfügung gestellt hat: gittf.codeplex.com

— jessehouwing

1

benutze git-tfs. Im Moment ist es viel besser als git-tf !!! github.com/git-tfs/git-tfs

— Philippe

3

Diese ganze Antwort ist schnell veraltet. Microsoft hat dem Team Foundation Service Git-Unterstützung hinzugefügt und wird der nächsten Hauptversion von Team Foundation Server Unterstützung für Git hinzufügen.

— Jessehouwing

1

@Philippe: Ich habe beides versucht. Ein paar Unterschiede: 1) git-tf ist plattformübergreifend, während git-tfs nur unter Windows ausgeführt wird. 2) git-tfs schreibt Commit-Beschreibungen neu, wenn Sie "drücken", um die Änderungssatznummer einzuschließen, während git-tf Ihre lokalen Commit-Hashes intakt lässt.

— Joey Adams

@JoeyAdams 1) +1, das ist der einzige gute Grund, sich für git-tf zu entscheiden. 2) Sie können dies auch mit git-tfs mithilfe des checkinBefehls (anstelle von rcheckin) tun. Aber ich bevorzuge rcheckin, weil es eher die git-Methode ist, Dinge zu tun, und deshalb entscheiden wir uns für git;)

— Philippe

9

Für mich besteht der Hauptunterschied in allen Zusatzdateien, die TFS zu Ihrer Lösung (.vssscc) hinzufügt, um TFS zu unterstützen. Wir hatten kürzlich Probleme mit diesen Dateien, die dem falschen Zweig zugeordnet wurden, was zu einem interessanten Debugging führte ...

— Paddy
quelle

2

Guter Punkt hier. Git fügt den .gitOrdner hinzu, um alle Repository-Details zu verfolgen. TFS ändert mindestens Ihre .sln(oder sind es die .csproj?) Dateien, um den Speicherort des Remote-Repositorys darin abzulegen.

— CodingWithSpike

5

Ich würde vergessen, wie sehr ich es gehasst habe, wie VSS Ihre Dateien "für" Sie geändert hat.

— Paddy