Git vs Team Foundation Server [chiuso]

263

Ho presentato Git al mio team di sviluppo e tutti lo odiano tranne me. Vogliono sostituirlo con Team Foundation Server. Sento che questo è un enorme passo indietro, anche se non ho molta familiarità con TFS. Qualcuno con esperienza può confrontare il supporto di branching su TFS con il branching Git? Inoltre, in generale, quali sono i pro e i contro di TFS? Lo odierò dopo aver usato Git per alcuni anni?

git tfs tfvc

— Jacko
fonte

24

Affronti una battaglia in salita su questo. Git non è affatto maturo come svn / hg / tfs su Windows, il che non disturba molto i veterani di git, ma è un grosso mal di testa per i nuovi arrivati.

— Marcelo Cantos,

7

@Jacko: ho valutato git-per-Windows nelle ultime settimane. Sebbene sia notevolmente migliorato dall'ultima volta che l'ho visto circa un anno fa, è ancora molto lontano dall'essere pronto per la prima serata con i tipici sviluppatori Windows. Ad esempio, il plugin VS è francamente doloroso. Non è altro che un mucchio di opzioni di menu sotto la barra dei menu principale, che falliscono silenziosamente se viene selezionata la soluzione anziché un progetto. Non riesco a ottenere lo strumento di commit per indicizzare hunk e linee, che è la ragione principale per cui utilizzo git, e ottenere git gui (che è un'atrocità completa, da un POV di usabilità) è alquanto imbarazzante.

— Marcelo Cantos,

6

Sarò onesto con te, comunque; mi uccide a lasciar perdere. Contrariamente alla visione popolare là fuori secondo cui i due sono alla pari, trovo che il modello di Git sia molto più potente e logico. Mercurial non ha nulla che corrisponda all'indice di Git e odio il suo approccio alla ramificazione. Il concetto di etichette Git che ti muovi e sincronizzi tra i repository è molto elegante. I segnalibri di Mercurial sono l'unica cosa che si avvicina e sono un PITA da configurare per tutti. La linea di fondo, tuttavia, è che il successo è più probabile con svn → Mercurial che svn → git, dato il personale e la relativa maturità degli strumenti.

— Marcelo Cantos,

4

sì, Git governa quando si tratta di potenza ed eleganza. Ma non tutti sono pronti per questo.

— Jacko,

7

@JamesReategui: personalmente penso ( stackoverflow.com/a/11362998/520162 ) che l'integrazione di un VCS in un IDE è un meandro. Immagina se domani cambi il tuo IDE principale. Cosa succede se si rilascia VS per Eclipse? Sei davvero disposto a imparare una nuova integrazione VCS? Git è eccezionale sulla riga di comando ( stackoverflow.com/a/5645910/520162 ). Imparalo e scoprirai un mondo incredibilmente potente di controllo delle versioni.

— Verifica il

273

Penso, la dichiarazione

tutti lo odiano tranne me

rende ogni ulteriore discussione rifiuti: quando si continua a usare Git, si darà la colpa si se qualcosa va storto.

A parte questo, per me Git ha due vantaggi rispetto a un VCS centralizzato che apprezzo di più (come parzialmente descritto da Rob Sobers ):

backup automatico di tutto il repository: ogni volta che qualcuno estrae dal repository centrale, ottiene una cronologia completa delle modifiche. Quando un repository si perde: non preoccuparti, prendi uno di quelli presenti su ogni workstation.
accesso repository offline: quando lavoro a casa (o in aereo o in treno), posso vedere la cronologia completa del progetto, ogni singolo check-in, senza avviare la mia connessione VPN per lavorare e posso lavorare come se fossi al lavoro : check-in, check-out, filiale, qualsiasi cosa.

Ma come ho detto: penso che stai combattendo una battaglia persa: quando tutti odiano Git, non usare Git. Potrebbe aiutarti di più a sapere perché odiano Git invece di provarli per convincerli.

Se semplicemente non lo vogliono perché è nuovo per loro e non sono disposti a imparare qualcosa di nuovo: sei sicuro di fare uno sviluppo di successo con quel personale?

In realtà ogni singola persona odia Git o sono influenzati da alcuni opinion leader? Trova i leader e chiedi loro qual è il problema. Convincili e convincerai il resto della squadra.

Se non riesci a convincere i leader: dimentica di usare Git, prendi il TFS. Ti semplifica la vita.

— Eckes
fonte

22

Dai, diamine. Mi danno la colpa ogni volta che qualcosa va storto. Non se stessi per non aver imparato come funziona. Per me, Git è il più vicino alla perfezione che abbia mai visto in un sistema di controllo della versione.

— Jacko,

15

D'altra parte TFS include il rilevamento di difetti / elementi di lavoro, rapporti, ... e altre funzioni. Quindi Git vs TFS solo sulla funzionalità VCS manca piuttosto il punto di TFS.

— Richard,

5

@Dan see rebase, filter-tree ...

— Artefacto

7

@Artefacto Lo so, ma poi tutti i tag di commit cambiano e tutti i metadati (discussioni sulla revisione del codice, ecc.) Sono orfani o devono essere aggiornati. Tuttavia, un mese con TFS mi ha convinto che non è nella lega di Git come sistema di controllo della versione. Git libera lo sviluppatore di essere produttivo in modi che devono essere sperimentati per essere compresi. Il ramo come metafora del blocco appunti è malvagio potente.

— Dan Solovay,

6

@Richard Direi che è un aspetto negativo di TFS: una volta che sei dentro, sei tutto dentro. Fa tutto mediocre e non ti dà una scelta al riguardo. Esistono strumenti di gran lunga migliori per tenere traccia degli elementi di lavoro, dei report e della gestione dei progetti.

— Ben Collins,

102

La differenza fondamentale tra i due sistemi è che TFS è un sistema di controllo versione centralizzato e Git è un sistema di controllo versione distribuito.

Con TFS, i repository sono archiviati su un server centrale e gli sviluppatori eseguono il checkout di una copia funzionante, che è un'istantanea del codice in un determinato momento. Con Git, gli sviluppatori clonano l' intero repository sui loro computer, compresa tutta la cronologia.

Un vantaggio di avere il repository completo sulle macchine dello sviluppatore è la ridondanza nel caso in cui il server muoia. Un altro vantaggio è che puoi spostare la tua copia di lavoro avanti e indietro tra le revisioni senza mai parlare con il server, il che può essere utile se il server è inattivo o semplicemente irraggiungibile.

Per me, il vero vantaggio è che puoi eseguire il commit dei changeset nel tuo repository locale senza mai parlare con il server o infliggere modifiche potenzialmente instabili al tuo team (ovvero, interrompere la build).

Ad esempio, se sto lavorando a una grande funzionalità, potrebbe volerci una settimana per programmare e testarlo completamente. Non voglio effettuare il check-in del codice instabile a metà settimana e interrompere la build, ma cosa succede se mi sto avvicinando alla fine della settimana e accidentalmente eseguo il bork dell'intera mia copia di lavoro? Se non mi impegno da sempre, corro il rischio di perdere il lavoro. Questo non è un controllo efficace della versione e TFS è suscettibile a questo.

Con DVCS, posso impegnarmi costantemente senza preoccuparmi di interrompere la build, perché sto impegnando le mie modifiche a livello locale . In TFS e altri sistemi centralizzati non esiste il concetto di un check-in locale.

Non ho nemmeno approfondito il modo in cui le ramificazioni e le fusioni sono migliori in DVCS, ma puoi trovare tonnellate di spiegazioni qui su SO o tramite Google. Posso dirti per esperienza che la ramificazione e l'unione in TFS non è buona.

Se l'argomento per TFS nella tua organizzazione è che funziona meglio su Windows che su Git, suggerirei Mercurial, che funziona benissimo su Windows: c'è l'integrazione con Windows Explorer (TortoiseHg) e Visual Studio (VisualHg).

— Rob Sobers
fonte

5

Se pensi di andare con Mercurial, Joel Spolsky ha un eccellente sito tutorial per educare la tua squadra: hginit.com

— Martin Owen,

3

Potrebbe valere la pena di ricordare che git è perfettamente capabable di emulare un sistema centralizzato, ed è comune avere un server git primario per tutti gli utenti, è solo che non devi farlo in questo modo.

— Tim Abell,

7

se stai lavorando su un pezzo di funzionalità che potrebbe spezzare altre cose - non potresti semplicemente creare un ramo in TFS? Certo - il ramo è su un server centrale - ma importa davvero? Sembra che tu possa fare effettivamente la stessa cosa in entrambi - sembra più una domanda su quale IDE stai usando e quanto bene sia integrato il sistema di controllo della versione con esso -

— William

13

Se stai lavorando a una grande funzionalità che potenzialmente potrebbe interrompere il team, si consiglia di utilizzare un ramo di funzionalità e, quando è pronto, unirti al ramo di sviluppo.

— Mike Cheel,

9

@MikeCheel Questo è un grande commento. Puoi anche creare uno Shelve del tuo codice ogni giorno ed eliminarli quando finalmente

— esegui il

86

Le persone hanno bisogno di posare la pistola, allontanarsi dalla sporgenza e pensare per un minuto. Si scopre che ci sono vantaggi oggettivi, concreti e innegabili per DVCS che faranno una GRANDE differenza nella produttività di una squadra.

Tutto dipende da Branching and Merging.

Prima del DVCS, il principio guida era "Prega Dio che non devi entrare in ramificazioni e fusioni. E se lo fai, almeno pregalo di lasciare che sia molto, molto semplice".

Ora, con DVCS, la ramificazione ( e la fusione ) è molto migliorata, il principio guida è: "Fallo in un attimo. Ti darà una tonnellata di benefici e non causerà alcun problema".

E questo è un ENORME booster di produttività per qualsiasi squadra.

Il problema è che le persone per capire cosa ho appena detto ed essere convinte che sia vero, devono prima investire in un po 'di una curva di apprendimento. Non devono imparare Git o qualsiasi altro DVCS stesso ... devono solo imparare come Git fa ramificazione e fusione. Leggi e rileggi alcuni articoli e post di blog, prendendoli lentamente e lavorando fino a quando non li vedi. Ciò potrebbe richiedere la parte migliore di 2 o 3 giorni interi.

Ma una volta che lo vedi, non prenderai nemmeno in considerazione la scelta di un non DVCS. Perché ci sono davvero chiari, obiettivi, concreti vantaggi per il DVCS e le maggiori vittorie sono nel settore delle ramificazioni e delle fusioni.

— Charlie Flowers
fonte

3

Grazie Charlie. Lo so e tu lo sai, ma è difficile entrare in contatto con persone che dicono cose come "l'integrazione del controllo del codice sorgente con Visual Studio è la caratteristica più importante per me"

— Jacko,

58

Lo so. Un amico e io stavamo analizzando questa analogia: immagina di aver bisogno di un serio database relazionale. Si valuta SQL Server, Oracle e MS Access. Alla fine si sceglie Access perché ha la GUI più bella, nonostante non sia in grado di ridimensionarsi, non imponga molto bene l'integrità referenziale, ecc. Branching e Merging sono la carne e le patate assolute di un sistema di controllo delle versioni. Qualsiasi altra caratteristica è solo un po 'bling sul lato. Ma le persone stanno facendo delle scelte basate sul bling.

— Charlie Flowers,

17

Mentre tendo ad essere d'accordo con le tue dichiarazioni, non vedo perché la ramificazione e la fusione di Git sia "migliore" solo perché è un sistema "distribuito". Non sono sicuro che essere un DVCS abbia a che fare con la sua capacità di fondersi. Mi piacerebbe una spiegazione del perché la fusione è più facile in un sistema distribuito. Nella mia esperienza, che è principalmente Git e Svn, la fusione in SVN è terribile non perché è un VCS centralizzato, ma perché non tiene traccia correttamente delle revisioni tra filiali come GIT.

— CodingWithSpike

8

@ rally25rs - Sono d'accordo per la maggior parte. Non c'è motivo per cui un VCS non possa essere anche bravo a fondersi. Non ce ne sono ancora (che io conosca). Ma la parte con cui non sono d'accordo è "semplicemente scrivendo meglio le routine di fusione che risolvono meglio i conflitti". La salsa segreta non è nelle routine di fusione più intelligenti, ma nell'adottare un approccio fondamentalmente diverso alle informazioni archiviate nel repository e al modo in cui le organizzate. Principalmente, rendendo Commits il fondamento dello stato interno. Gli impegni non sono solo un bel fulmine ... sono il fondamento delle capacità.

— Charlie Flowers,

10

@ rally25rs sono totalmente d'accordo re: si impegna a essere l'unità di lavoro atomica. Non solo la maggior parte dei sistemi centralizzati non organizza i dati in questo modo, ma scoraggia il tipo di lavoro momento per momento che gli sviluppatori devono fare per fare davvero un buon lavoro di succursale e fusione. I sistemi distribuiti incoraggiano ciò che chiamo commit "appositi" (autonomi, piccoli commit di lavori pertinenti con buone descrizioni) e i sistemi centralizzati incoraggiano quelli che chiamo "bombe diff" dove si buca in una caverna fino a quando non si è pronti e poi si trascinano giorni (o settimane) vale la pena lavorare sul sistema. Indovina quale tipo si fonde meglio?

— Ben Collins,

45

Originale : @Rob, TFS ha qualcosa chiamato " Scaffalature " che affronta la tua preoccupazione di commettere lavori in corso senza che ciò influisca sulla build ufficiale. Mi rendo conto che vedi il controllo centrale della versione come un ostacolo, ma per quanto riguarda TFS, il controllo del codice nello scaffale può essere visto come un punto di forza b / c, quindi il server centrale ha una copia del tuo work-in-progress nel raro evento la macchina locale si arresta in modo anomalo o viene persa / rubata oppure è necessario cambiare marcia rapidamente. Il mio punto è che TFS dovrebbe essere elogiato in questo campo. Inoltre, la ramificazione e l'unione in TFS2010 sono state migliorate rispetto alle versioni precedenti e non è chiaro a quale versione ti riferisci quando dici "... dall'esperienza che la ramificazione e l'unione in TFS non è buona". Disclaimer: sono un utente moderato di TFS2010.

Modifica Dec-5-2011 : Per l'OP, una cosa che mi preoccupa per TFS è che insiste sull'impostazione di tutti i file locali su "sola lettura" quando non ci si lavora. Se si desidera apportare una modifica, il flusso è che è necessario "estrarre" il file, che cancella l'attributo di sola lettura sul file in modo che TFS sappia tenerlo d'occhio. Questo è un flusso di lavoro scomodo. Il modo in cui preferirei che funzioni è che rileva automaticamente se ho apportato una modifica e non si preoccupa / si preoccupa affatto degli attributi del file. In questo modo, posso modificare il file in Visual Studio, o Blocco note o con qualsiasi strumento per favore. Il sistema di controllo della versione dovrebbe essere il più trasparente possibile al riguardo. Esiste un'estensione di Windows Explorer ( TFS PowerTools) che ti consente di lavorare con i tuoi file in Esplora risorse, ma ciò non semplifica molto il flusso di lavoro.

— Lee Grissom
fonte

2

Questo risponde alla domanda, non dovrebbe essere un commento, anche se tu avessi il rappresentante.

— SingleNegationElimination

8

Cordiali saluti - TFS "11" non richiede più il bit di sola lettura se si utilizzano aree di lavoro locali che è l'impostazione predefinita ora. Scopre in modo intelligente quali file vengono modificati da qualsiasi applicazione. Brian Harry ha qualche informazione in più sui miglioramenti qui: blogs.msdn.com/b/bharry/archive/2011/08/02/…

— Ed Blankenship

2

@EdBlankenship, grazie mille per quel link al blog. Questa è un'ottima notizia per vedere che l'assurdità del bit di sola lettura è stata indirizzata per rendere molto più semplice l'utilizzo della prossima versione di TFS.

— Lee Grissom,

7

Contrariamente a quanto si impegna in un ramo come fai con Git, lo scaffalatura non è facile da capire e da gestire. Non sai ad ogni commit che è stata fatta la scaffalatura e spesso hai problemi con l'unione (se da allora hai apportato modifiche, spesso vengono perse). I rami Git sono molto più potenti e comprensibili degli scaffali. La scaffalatura è per gli sviluppatori che non hanno mai sperimentato qualcos'altro ....

— Philippe,

2

Questo flusso di lavoro di "check-out" di un file ricorda Visual SourceSafe, in quanto questo era il modo comune di lavorare; i file sono stati recuperati da SourceSafe e archiviati localmente come file di sola lettura. Il check out di un file o di un gruppo di file potrebbe essere contrassegnato come esclusivo, il che significa che altri potrebbero vedere il set di file su cui sta lavorando un altro sviluppatore, in modo da impedire la necessità di unire quando la ramificazione è stata disabilitata (probabilmente a causa di un maiale giusto in VSS).

— Brett Rigby,

18

Oltre a tutto ciò che è stato detto (

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

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

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

), che è corretto, TFS non è solo un VCS. Una delle principali funzionalità fornite da TFS è la funzionalità di tracciamento dei bug integrata in modo nativo. I changeset sono collegati a problemi e potrebbero essere monitorati. Sono supportati vari criteri per i check-in, nonché l'integrazione con il dominio Windows, che è ciò che hanno le persone che eseguono TFS. Un'interfaccia grafica strettamente integrata con Visual Studio è un altro punto di forza, che fa appello allo sviluppatore mouse e clic ~~inferiore alla media~~ e al suo manager.

Quindi confrontare Git con TFS non è una domanda corretta da porre. La domanda corretta, sebbene poco pratica, è quella di confrontare Git con la sola funzionalità VCS di TFS. A quel punto, Git soffia TFS fuori dall'acqua. Tuttavia, qualsiasi team serio ha bisogno di altri strumenti ed è qui che TFS fornisce una destinazione di arresto.

— Sherlock
fonte

4

Si prega di ottenere gli stessi strumenti forniti da TFS in qualsiasi applicazione di strumento agile. Rally, lo chiami.

— Positivo

2

Anche se concordo sul fatto che TFS ha un obiettivo più ampio, lo riformulerei in "TENTA di fornire una destinazione unica", ma non è abbastanza buono (almeno non l'opzione migliore) in nessuno dei compiti che tenta di risolvere; quindi è come un coltello svizzero smussato.

— slashCoder

@PositiveGuy non puoi ottenerlo senza lavoro e configurazione. TFS ti dà tutto con un clic. Caso in questione, l'intero ecosistema è ora disponibile come servizio cloud, senza necessità di configurazione. Se riesco a ottenere il controllo della versione, il supporto di mischia, le build automatizzate, il lab di test e la gestione del piano di test, tutti integrati immediatamente con se stessi E un LDAP aziendale (mentire AzureAD), per $ 10 / mese, perché nella mia mente andrei stai cercando di incollare pezzi da solo?

— Craig Brunetti,

1

@slashCoder come ci si può aspettare che una suite completa sia la migliore in ogni pezzo? Il costo della sua non-educazione è davvero maggiore del costo di dover gestire l'integrazione dei componenti da solo? ... forse per alcuni posti lo fa, posso vederlo. Ma è puro sovraccarico dover gestire tali cose. Cosa succede se il GIT aziendale funziona correttamente, ma l'istanza JIRA non funziona e l'aggiornamento Jenkins non vola? Destra? È come giocoleria motoseghe. A fuoco. Semi-bendato. :) :)

— Craig Brunetti,

17

Se il tuo team utilizza TFS e desideri utilizzare Git, potresti prendere in considerazione un bridge "git to tfs". In sostanza, lavori quotidianamente usando Git sul tuo computer, quindi quando vuoi inviare le tue modifiche, le invii al server TFS.

Ce ne sono un paio là fuori (su Github). Ne ho usato uno nel mio ultimo posto (insieme a un altro sviluppatore) con un certo successo. Vedere:

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

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

— bytedev
fonte

6

Microsoft fornisce ora un'integrazione diretta con i repository Git e TFS: blogs.msdn.com/b/bharry/archive/2012/08/13/…

— Ed Blankenship,

1

@EdBlankenship, potresti voler convertire il tuo commento in una risposta. Sembra essere un'ottima soluzione per l'OP. Voterò per questo. :)

— Lee Grissom,

1

Tranne se ti trovi su una piattaforma diversa da Windows, dovresti preferire git-tfs! git-tf è tutt'altro che buono come git-tfs ... E la filosofia è orientata al TFS mentre git-tfs è più orientata al git (ed è quello che vogliamo!)

— Philippe

15

Dopo alcune indagini tra pro e contro, la società con cui sono stato coinvolto ha anche deciso di optare per TFS. Non perché GIT non è un buon sistema di controllo della versione, ma soprattutto per la soluzione ALM completamente integrata fornita da TFS. Se solo la funzione di controllo della versione fosse importante, probabilmente la scelta potrebbe essere stata GIT. La ripida curva di apprendimento GIT per gli sviluppatori regolari potrebbe tuttavia non essere sottovalutata.

Vedi una spiegazione dettagliata nel mio post sul blog TFS come una vera piattaforma multi-tecnologia .

— Pieter Gheysens
fonte

3

Forse, ma ogni parte di TFS è cattiva e difficile da amministrare (in effetti, è necessario un vero amministratore per TFS). Guarda Git> TFS (VCS), Jenkins> TFS (CI), nunit o xunit> mstest, IceScrum o ...> TFS (Project Management). TFS è una buona idea all'inizio, fino a quando non lo usi !!!

— Philippe,

1

perché hai bisogno di TFS, basta avere una buona app agile. E poi usa Git o sovversione e sei sulla buona strada. TFS ti ostacola bloccandoti con problemi.

— Positivo

Aggiornamento: TFS 2013 (server) [e VS12-13) ora supporta git per il controllo della versione. Quindi puoi ottenere il meglio da entrambi i mondi

— Darcy Thomas

2

Certo, è bello avere un ALM completamente integrato. Ma non a scapito della flessibilità. IMO. un ALM dovrebbe essere costruito con la massima tecnologia "best of breed" possibile ... o almeno, la flessibilità necessaria per integrare il meglio delle razze, poiché è probabile che cambino nel tempo. La scelta di TFS sta fondamentalmente mettendo una posta in gioco, dicendo "Microsoft vincerà in tutti gli aspetti del mio ALM", il che è sciocco. Ho usato Git w / Jira, ad esempio, che mi ha permesso di aggiornare / chiudere i problemi in base al mio messaggio di commit. Nella mia esperienza (molto anche con TFS), questo è un flusso di lavoro di gran lunga superiore.

— Scott Silvi,

1

La barra laterale - anche con l'integrazione di TFS / Git, in pratica stai dicendo "lascia andare VCS a Git, mantenendo il monitoraggio dei problemi" - fondamentalmente non è diverso dall'uso di Git con qualsiasi altro software di rilevamento dei problemi. Quindi non sono più sicuro che l'argomento ALM sia più valido, dati i tentativi di flessibilità di Microsoft (che applaudo).

— Scott Silvi,

14

L'intera cosa distribuita di Git è davvero eccezionale. offre alcune funzionalità che gli Shelfet non hanno (nel prodotto corrente) come le opzioni di rollback e commit locali (come la funzionalità di cronologia locale di Eclipse ). Puoi alleviarlo usando i rami degli sviluppatori, ma siamo onesti, a molti sviluppatori non piace ramificare e unire un po '. Mi è stato chiesto di attivare la funzionalità "checkout esclusivo" di vecchio stile in TFS troppo spesso (e negata ogni volta).

Penso che molte grandi aziende siano abbastanza spaventate da consentire a uno sviluppatore di portare tutta la storia in uno spazio di lavoro locale e portarla con sé (per esempio a un nuovo datore di lavoro) ... Rubare un'istantanea è male, ma portare via un'intera storia è ancora più problematico. (Non che tu non possa ottenere una cronologia completa da TFS di te lo volevi) ...

Si dice che è un ottimo modo per eseguire il backup, il che è ottimo per l'open source di nuovo in cui il manutentore originale potrebbe smettere di occuparsi e rimuove la sua versione, ma per un piano aziendale questo non è ancora valido per molte aziende in quanto non esiste una chiara assegnazione di responsabilità per mantenere i backup. E sarebbe difficile capire quale versione usare se il 'progetto' principale svanisce in qualche modo. Che tenderebbe a nominare un repository come principale / centrale.

Quello che mi piace di più di Git è l'opzione Push / Pull, in cui puoi facilmente contribuire con il codice a un progetto senza la necessità di disporre dei diritti di commit. Immagino che potresti imitare utenti e scaffali molto limitati in TFS per imitare questo, ma non è potente come l'opzione Git. Anche la ramificazione tra progetti di team potrebbe funzionare, ma dal punto di vista amministrativo non è realmente fattibile per molte organizzazioni poiché l'aggiunta di progetti di team aggiunge un sacco di costi amministrativi.

Vorrei anche aggiungere alle cose menzionate nell'area di controllo non sorgente. Funzionalità come il monitoraggio degli oggetti di lavoro, la creazione di report e l'automazione della costruzione (compresa la gestione del laboratorio) traggono grande vantaggio da un repository principale centrale. Questi diventano molto più difficili quando si utilizza un modello distribuito puro, a meno che non si crei uno dei nodi principali (e quindi si ritorni a un modello meno distribuito).

Con TFS Basic in arrivo con TFS 11, potrebbe non essere lontano aspettarsi un TFS distribuito che ti consenta di sincronizzare il tuo TFS di base locale con un TFS centrale nell'era di TFS 12+. Metterò il mio voto per quello in basso nel servizio !

— jessehouwing
fonte

Ti interesserà anche questa nuova funzionalità offerta da Microsoft: gittf.codeplex.com

— jessehouwing

1

usa git-tfs. Per il momento, è molto meglio di git-tf !!! github.com/git-tfs/git-tfs

— Philippe

3

Tutta questa risposta sta rapidamente diventando obsoleta. Microsoft ha aggiunto il supporto Git al servizio Team Foundation e aggiungerà il supporto per Git alla prossima versione principale di Team Foundation Server.

— jessehouwing,

1

@Philippe: ho provato entrambi. Un paio di differenze: 1) git-tf è multipiattaforma, mentre git-tfs funziona solo su Windows. 2) git-tfs riscrive le descrizioni dei commit quando si "spinge" per includere il numero del changeset, mentre git-tf lascia intatti gli hash di commit locali.

— Joey Adams,

@JoeyAdams 1) +1, questa è l'unica buona ragione per scegliere git-tf 2) Puoi anche farlo con git-tfs usando il checkincomando (invece di rcheckin). Ma preferisco rcheckin perché è più il modo git di fare le cose ed è per questo che scegliamo di usare git;)

— Philippe

9

Per me la differenza principale sono tutti i file ausiliari che TFS aggiungerà alla tua soluzione (.vssscc) per "supportare" TFS: abbiamo avuto problemi recenti con questi file che finiscono per essere mappati sul ramo sbagliato, il che porta ad alcuni interessanti debug ...

— Paddy
fonte

2

Buon punto qui. Git aggiungerà la .gitcartella per tenere traccia di tutti i dettagli del repository. TFS modificherà almeno i tuoi .sln(o è il .csproj?) File per inserire la posizione del repository remoto in esso.

— CodingWithSpike

5

Mi sarei dimenticato quanto odiavo come VSS avrebbe modificato i tuoi file "per" te.

— Paddy,