Git vs Team Foundation Server [fechado]

263

Apresentei o Git à minha equipe de desenvolvimento e todo mundo odeia, exceto eu. Eles querem substituí-lo pelo Team Foundation Server. Sinto que este é um grande passo para trás, embora não esteja muito familiarizado com o TFS. Alguém com experiência pode comparar o suporte a ramificação no TFS com a ramificação Git? Além disso, em geral, quais são os prós e os contras do TFS? Eu odeio isso depois de usar o Git por alguns anos?

git tfs tfvc

— Jacko
fonte

24

Você enfrenta uma batalha difícil nessa. O Git não é nem de longe tão maduro quanto o svn / hg / tfs no Windows, o que não incomoda muito os veteranos do git, mas é uma grande dor de cabeça para os novatos.

— Marcelo Cantos

7

@ Jacko: Estive avaliando o git-for-Windows nas últimas semanas. Embora tenha melhorado bastante desde a última vez que o olhei, há um ano, ainda está muito longe de estar pronto para o horário nobre com os desenvolvedores típicos do Windows. Por exemplo, o plug-in VS é francamente lamentável. Não são nada além de várias opções de menu na barra de menus principal, que falham silenciosamente se a solução for selecionada em vez de um projeto. Não consigo obter a ferramenta de consolidação para indexar blocos e linhas, que é a principal razão pela qual eu uso o git, e chegar ao git gui (que é uma atrocidade completa, de um POV de usabilidade) é, na melhor das hipóteses, estranho.

— Marcelo Cantos

6

Serei honesto com você; isso me mata a largar o git. Ao contrário da visão popular de que os dois estão em pé de igualdade, acho o modelo do git muito mais poderoso e lógico. O Mercurial não tem nada para corresponder ao índice do git, e eu odeio sua abordagem de ramificação. O conceito de etiquetas do Git que você move e sincroniza entre repos é muito elegante. Os marcadores de mercado da Mercurial são a única coisa que se aproxima e são uma PITA a ser configurada para todos. O ponto principal, porém, é que o sucesso é mais provável com svn → Mercurial do que svn → git, dada a equipe e a maturidade relativa das ferramentas.

— Marcelo Cantos

4

sim, o Git governa quando se trata de poder e elegância. Mas nem todo mundo está pronto para isso.

— Jacko

7

@ JamesReategui: Eu pessoalmente acho ( stackoverflow.com/a/11362998/520162 ) que a integração de um VCS em um IDE é um meandro. Imagine se você estiver trocando seu IDE principal amanhã. E se você soltar o VS for Eclipse? Você está realmente disposto a aprender uma nova integração VCS? O Git é excelente na linha de comando ( stackoverflow.com/a/5645910/520162 ). Aprenda e você descobrirá um mundo incrivelmente poderoso de controle de versão.

— Eckes

273

Eu acho que a afirmação

todo mundo odeia, exceto eu

faz qualquer outra resíduos discussão: quando você continuar a usar Git, eles vão culpar você se alguma coisa der errado.

Além disso, para mim, o Git tem duas vantagens sobre um VCS centralizado que eu mais aprecio (como descrito em parte por Rob Sobers ):

backup automático de todo o repositório: sempre que alguém sai do repositório central, ele obtém um histórico completo das alterações. Quando um repositório se perde: não se preocupe, leve um dos presentes em todas as estações de trabalho.
acesso repo offline: quando estou trabalhando em casa (ou em um avião ou trem), posso ver o histórico completo do projeto, cada check-in, sem iniciar minha conexão VPN para funcionar e trabalhar como se estivesse no trabalho : check-in, check-out, filial, qualquer coisa.

Mas como eu disse: acho que você está travando uma batalha perdida: quando todo mundo odeia o Git, não use o Git. Poderia ajudar você a saber mais por que eles odeiam o Git em vez de tentar convencê-los.

Se eles simplesmente não querem, porque é novo para eles e não estão dispostos a aprender algo novo: você tem certeza de que fará um desenvolvimento bem-sucedido com essa equipe?

Realmente todas as pessoas odeiam o Git ou são influenciadas por alguns líderes de opinião? Encontre os líderes e pergunte-lhes qual é o problema. Convença-os e você convencerá o resto da equipe.

Se você não conseguir convencer os líderes: esqueça de usar o Git, use o TFS. Facilitará sua vida.

— eckes
fonte

22

Bang, querida. Eles me culpam sempre que algo dá errado. Não eles mesmos por não aprenderem como funciona. Para mim, o Git está o mais próximo da perfeição que já experimentei em um sistema de controle de versão.

— Jacko

15

Por outro lado, o TFS inclui rastreamento de defeitos / itens de trabalho, relatórios, ... e outras funções. Portanto, Git vs TFS apenas na funcionalidade VCS está perdendo o objetivo do TFS.

— Richard

5

@Dan see rebase, filter-tree ...

— Artefacto

7

@Artefacto eu sei, mas todas as tags de confirmação mudam e todos os metadados (discussões de revisão de código etc.) ficam órfãos ou precisam ser atualizados. No entanto, um mês com o TFS me convenceu de que não está na liga do Git como sistema de controle de versão. O Git libera o desenvolvedor para ser produtivo de maneiras que precisam ser experimentadas para serem entendidas. O ramo como metáfora da almofada de rascunho é muito poderoso.

— precisa

6

@ Richard Eu diria que isso é uma desvantagem do TFS: quando você entra, você entra. Faz tudo medíocre e não oferece uma escolha a respeito. Existem ferramentas muito melhores para rastrear itens de trabalho, relatórios e gerenciamento de projetos.

— Ben Collins

102

A principal diferença entre os dois sistemas é que o TFS é um sistema de controle de versão centralizado e o Git é um sistema de controle de versão distribuído.

Com o TFS, os repositórios são armazenados em um servidor central e os desenvolvedores fazem check-out de uma cópia de trabalho, que é uma captura instantânea do código em um momento específico. Com o Git, os desenvolvedores clonam o repositório inteiro em suas máquinas, incluindo todo o histórico.

Um benefício de ter o repositório completo nas máquinas do desenvolvedor é a redundância, caso o servidor morra. Outra vantagem interessante é que você pode mover sua cópia de trabalho para frente e para trás entre as revisões sem nunca falar com o servidor, o que pode ser útil se o servidor estiver inoperante ou inacessível.

Para mim, o verdadeiro benefício é que você pode confirmar conjuntos de alterações no seu repositório local sem nunca falar com o servidor ou infligir alterações potencialmente instáveis à sua equipe (ou seja, interromper a compilação).

Por exemplo, se estou trabalhando em um grande recurso, pode demorar uma semana para codificá-lo e testá-lo completamente. Não quero fazer check-in de código instável no meio da semana e interromper a compilação, mas o que acontece se eu estiver chegando ao final da semana e acidentalmente copiar minha cópia de trabalho inteira? Se eu não cometer o tempo todo, corro o risco de perder meu trabalho. Isso não é controle de versão eficaz e o TFS é suscetível a isso.

Com o DVCS, posso confirmar constantemente sem me preocupar em interromper a compilação, porque estou comprometendo minhas alterações localmente . No TFS e em outros sistemas centralizados, não há conceito de check-in local.

Eu nem sequer me deparei com o quão melhor é a ramificação e a fusão no DVCS, mas você pode encontrar toneladas de explicações aqui no SO ou no Google. Por experiência, posso dizer que ramificar e mesclar no TFS não é bom.

Se o argumento para o TFS na sua organização é que ele funciona melhor no Windows do que no Git, sugiro o Mercurial, que funciona muito bem no Windows - há integração com o Windows Explorer (TortoiseHg) e o Visual Studio (VisualHg).

— Rob Sobers
fonte

5

Se você pensa em usar o

— Martin Owen

3

Vale a pena mencionar que o git é perfeitamente capaz de emular um sistema centralizado, e é comum ter um servidor git primário para todos os usuários, mas você não precisa fazê-lo dessa maneira.

— Tim Abell

7

se você estiver trabalhando em uma parte da funcionalidade que pode quebrar outras coisas - não poderia simplesmente criar uma ramificação no TFS? Claro - a filial está em um servidor central - mas isso realmente importa? Parece que você pode efetivamente fazer a mesma coisa em ambos - parece mais uma questão de qual IDE você está usando e quão bem integrado o sistema de controle de versão está com ele - #

— William

13

Se você estiver trabalhando em um grande recurso que potencialmente poderia interromper a equipe, é recomendável usar um ramo de recursos e, quando pronto, mesclar-se ao ramo de desenvolvimento.

— Mike Cheel

9

@MikeCheel Este é um ótimo comentário. Você também pode criar um Shelve do seu código a cada dia e excluí-los quando você finalmente o check-in o seu recurso (mas a idéia ramificação é a melhor maneira de fazê-lo)

— RPDeshaies

86

As pessoas precisam abaixar a arma, afastar-se da borda e pensar por um minuto. Acontece que existem vantagens objetivas, concretas e inegáveis para o DVCS que farão uma enorme diferença na produtividade de uma equipe.

Tudo se resume a ramificação e fusão.

Antes do DVCS, o princípio norteador era "Ore a Deus para que você não precise se ramificar e se fundir. E se o fizer, pelo menos implore a Ele para que seja muito, muito simples".

Agora, com o DVCS, a ramificação ( e a mesclagem ) é muito aprimorada, o princípio norteador é: "Faça isso rapidamente. Isso oferecerá muitos benefícios e não causará problemas".

E isso é um enorme aumento de produtividade para qualquer equipe.

O problema é que, para as pessoas entenderem o que acabei de dizer e convencidas de que é verdade, elas precisam primeiro investir em um pouco de uma curva de aprendizado. Eles não precisam aprender o Git ou qualquer outro DVCS ... eles precisam aprender como o Git se ramifica e se funde. Leia e releia alguns artigos e postagens do blog, devagar e trabalhando até que você o veja. Isso pode levar a maior parte de 2 ou 3 dias completos.

Mas, depois de ver isso, você nem considerará escolher um não DVCS. Porque realmente existem vantagens claras, objetivas e concretas no DVCS, e as maiores vitórias estão na área de ramificação e fusão.

— Charlie Flowers
fonte

3

Obrigado Charlie. Eu sei, e você sabe disso, mas é difícil para chegar até as pessoas que dizem coisas como "a integração de controle de origem com o Visual Studio é a característica mais importante para mim"

— Jacko

58

Eu sei. Eu e um amigo estávamos fazendo essa analogia - imagine que você precise de um banco de dados relacional sério. Você avalia o Sql Server, Oracle e MS Access. Você acaba escolhendo o Access porque ele tem a melhor interface do usuário, apesar de não poder ser dimensionado, não impõe muito bem a integridade referencial, etc. Ramificação e mesclagem são a carne e as batatas absolutas de um sistema de controle de versão. Qualquer outra característica é apenas um pouco de lado. Mas as pessoas estão fazendo escolhas com base no bling.

— Charlie Flowers

17

Embora eu tenha concordado com suas declarações, não vejo por que a ramificação e fusão do Git são "melhores" apenas porque é um sistema "distribuído". Não tenho certeza de que ser um DVCS tenha algo a ver com sua capacidade de mesclar. Eu adoraria uma explicação de por que a fusão é mais fácil em um sistema distribuído. Na minha experiência, que é principalmente Git e Svn, a fusão no SVN é terrível, não porque é um VCS centralizado, mas porque não rastreia adequadamente as revisões entre os ramos, como o GIT.

— CodingWithSpike

8

@ rally25rs - concordo com a maior parte disso. Não há razão para que um VCS não possa ser bom em mesclar também. Ainda não há nenhum (que eu saiba). Mas a parte em que discordo é "puramente escrevendo rotinas de melhor mesclagem que resolvem melhor os conflitos". O molho secreto não está em rotinas de mesclagem mais inteligentes, mas em uma abordagem fundamentalmente diferente das informações armazenadas no repositório e como você as organiza. Principalmente, tornando Commits a base do estado interno. As confirmações não são apenas uma solução interessante ... elas são a base dos recursos.

— Charlie Flowers

10

@ rally25rs concorda totalmente que re: compromete-se a ser a unidade atômica do trabalho. Não apenas a maioria dos sistemas centralizados não organiza os dados dessa maneira, como desencorajam o tipo de trabalho momento a momento que os desenvolvedores precisam realizar para fazer um trabalho de ramificação e mesclagem realmente bom. Sistemas distribuídos incentivam o que chamo de compromissos "apropriados" (pequenos e independentes trabalhos relevantes, com boas descrições) e sistemas centralizados incentivam o que eu chamo de "bombas diferenciais", onde você fica em uma caverna até ficar pronto e depois perde dias (ou semanas) no valor de trabalho no sistema. Adivinha que tipo se funde melhor?

— Ben Collins

45

Original : @Rob, o TFS tem algo chamado " Shelving " que aborda sua preocupação em comprometer o trabalho em andamento sem afetar a compilação oficial. Sei que você vê o controle central de versão como um obstáculo, mas com relação ao TFS, verificar seu código na prateleira pode ser visto como uma força b / c, em seguida, o servidor central tem uma cópia do seu trabalho em andamento no evento raro sua máquina local trava ou é perdida / roubada ou você precisa mudar de marcha rapidamente. O que quero dizer é que o TFS deve receber elogios apropriados nessa área. Além disso, a ramificação e a mesclagem no TFS2010 foram aprimoradas em relação às versões anteriores, e não está claro a qual versão você está se referindo ao dizer "... por experiência própria, que a ramificação e a mesclagem no TFS não são boas". Isenção de responsabilidade: eu sou um usuário moderado do TFS2010.

Editar 5 de dezembro de 2011 : Para o OP, uma coisa que me incomoda sobre o TFS é que ele insiste em definir todos os seus arquivos locais como "somente leitura" quando você não está trabalhando neles. Se você deseja fazer uma alteração, o fluxo é que você deve fazer o "check-out" do arquivo, o que apenas limpa o atributo somente leitura no arquivo para que o TFS saiba ficar de olho nele. Esse é um fluxo de trabalho inconveniente. A maneira que eu preferiria que funcionasse é que apenas detecta automaticamente se fiz uma alteração e não se preocupa / se incomoda com os atributos do arquivo. Dessa forma, eu posso modificar o arquivo no Visual Studio ou no Bloco de Notas ou com qualquer ferramenta que eu queira. O sistema de controle de versão deve ser o mais transparente possível a esse respeito. Há uma extensão do Windows Explorer ( TFS PowerTools), que permite trabalhar com seus arquivos no Windows Explorer, mas isso não simplifica muito o fluxo de trabalho.

— Lee Grissom
fonte

2

Isso responde à pergunta, não deve ser um comentário, mesmo se você tiver o representante.

— SingleNegationElimination

8

FYI - TFS "11" não requer mais o bit somente leitura se você estiver usando espaços de trabalho locais, o que é o padrão agora. Ele descobre de maneira inteligente quais arquivos foram alterados em qualquer aplicativo. Brian Harry tem mais algumas informações sobre as melhorias aqui: blogs.msdn.com/b/bharry/archive/2011/08/02/…

— Ed Blankenship

2

@ EdBlankenship, muito obrigado pelo link do blog. É uma excelente notícia para ver que o absurdo pouco de leitura está sendo abordado para facilitar o uso da próxima versão do TFS.

— 21812 Lee Grissom

7

Ao contrário de confirmar em um ramo como você faz com o Git, não é fácil entender e gerenciar prateleiras. Você não sabe em cada confirmação que a prateleira foi feita e muitas vezes tem problemas com a mesclagem (se, desde então, fez modificações, elas geralmente são perdidas). O ramo Git é muito mais poderoso e compreensível do que as prateleiras. Prateleiras é para programadores que nunca experimentou algo mais ....

— Philippe

2

Esse fluxo de trabalho de 'check-out' de um arquivo é uma reminiscência do Visual SourceSafe, pois essa era a maneira comum de trabalhar; arquivos foram recuperados do SourceSafe e armazenados localmente como arquivos somente leitura. Verificar um arquivo ou vários arquivos pode ser marcado como exclusivo, o que significa que outras pessoas podem ver o conjunto de arquivos no qual outro desenvolvedor está trabalhando, para evitar a necessidade de mesclagem quando a ramificação foi desativada (provavelmente devido a porco direito no VSS).

— precisa saber é o seguinte

18

Além de tudo o que foi dito (

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

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

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

), que está correto, o TFS não é apenas um VCS. Um recurso importante que o TFS fornece é a funcionalidade de rastreamento de erros nativamente integrada. Os conjuntos de alterações estão vinculados a problemas e podem ser rastreados. Várias políticas para check-ins são suportadas, bem como a integração com o domínio do Windows, que é o que as pessoas que executam o TFS possuem. A GUI firmemente integrada ao Visual Studio é outro ponto de venda, que agrada a ~~menos de~~ um desenvolvedor de mouse e clique e seu gerente.

Portanto, comparar o Git ao TFS não é uma pergunta apropriada a ser feita. A pergunta correta, embora impraticável, é comparar o Git com apenas a funcionalidade VCS do TFS. Com isso, o Git sopra o TFS para fora da água. No entanto, qualquer equipe séria precisa de outras ferramentas e é aí que o TFS fornece um destino de parada.

— Sherlock
fonte

4

Você pode obter as mesmas ferramentas que o TFS fornece em qualquer aplicativo de ferramenta ágil. Rally, você escolhe.

— PositiveGuy

2

Embora eu concorde com o fato de o TFS ter um objetivo mais amplo, eu o reformularia como "TRIES para fornecer um destino único", mas não é bom o suficiente (pelo menos não é a melhor opção) em qualquer uma das tarefas que ele tenta executar. resolver; então é como uma faca suíça sem corte.

— slashCoder

@PositiveGuy você não pode obtê-lo sem trabalho e configuração. O TFS fornece tudo com um clique. Caso em questão, todo o ecossistema agora está disponível como um serviço em nuvem, com zero de configuração necessária. Se eu posso obter controle de versão, suporte a scrum, builds automatizados, laboratório de teste e gerenciamento de plano de teste, todos integrados imediatamente e um LDAP corporativo (por exemplo, AzureAD), por US $ 10 / mês, por que, no meu juízo perfeito, eu iria tentando colar peças por conta própria?

— Craig Brunetti

1

@slashCoder como é de esperar que qualquer suíte completa seja a melhor em cada peça? O custo de sua não melhor qualidade realmente supera o custo de ter que gerenciar a integração de componentes por conta própria? ... talvez em alguns lugares, eu posso ver isso. Mas é pura sobrecarga ter que executar essas coisas. O que acontece se o seu GIT corporativo estiver funcionando bem, mas sua instância do JIRA for desativada e sua atualização do Jenkins não funcionar? Certo? É como fazer malabarismos com motosserras. Em chamas. Semi-vendado. :) :)

— Craig Brunetti

17

Se sua equipe usa o TFS e você deseja usar o Git, considere uma ponte "git to tfs". Essencialmente, você trabalha no dia-a-dia usando o Git no seu computador e, quando deseja enviar suas alterações, envia-as para o servidor TFS.

Existem alguns por aí (no github). Eu usei um no meu último lugar (junto com outro desenvolvedor) com algum sucesso. Vejo:

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

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

— bytedev
fonte

6

A Microsoft fornece uma integração direta com repositórios Git e TFS agora: blogs.msdn.com/b/bharry/archive/2012/08/13/…

— Ed Blankenship

1

@ EdBlankenship, convém converter seu comentário em uma resposta. Parece ser uma ótima solução para o OP. Eu vou votar a favor. :)

— Lee Grissom

1

Exceto se você estiver em outra plataforma que não seja o Windows, você deve preferir o git-tfs! git-tf está longe de ser tão bom como git-TFS ... E a filosofia é TFS orientada enquanto git-TFS é mais git orientado (e isso é o que queremos!)

— Philippe

15

Depois de alguma investigação entre os prós e os contras, a empresa com a qual eu estava envolvido também decidiu optar pelo TFS. Não porque o GIT não é um bom sistema de controle de versão, mas o mais importante para a solução ALM totalmente integrada que o TFS oferece. Se apenas o recurso de controle de versão era importante, a escolha provavelmente poderia ter sido o GIT. A curva de aprendizado íngreme do GIT para desenvolvedores regulares pode, no entanto, não ser subestimada.

Veja uma explicação detalhada no meu blog TFS como uma verdadeira plataforma entre tecnologias .

— Pieter Gheysens
fonte

3

Talvez, mas cada parte do TFS seja ruim e difícil de administrar (na verdade, você precisa de um administrador real para o TFS). Procure Git> TFS (VCS), Jenkins> TFS (CI), unidade ou xunit> mstest, IceScrum ou ...> TFS (Gerenciamento de projetos). O TFS é uma boa ideia no começo, até você usá-lo !!!

— Philippe

1

Por que você precisa do TFS, basta obter um bom aplicativo ágil. E então use Git ou subversion e você estará a caminho. O TFS fica no seu caminho, atolando-o de problemas.

— PositiveGuy

Atualização: O TFS 2013 (servidor) [e VS12-13) agora suporta git para controle de versão. Então você pode obter o melhor dos dois mundos

— DarcyThomas

2

Claro, é bom ter um ALM totalmente integrado. Mas não à custa da flexibilidade. IMO. um ALM deve ser construído com o máximo possível de tecnologia "da melhor raça" ... ou, pelo menos, com a flexibilidade de integrar a melhor das raças, pois elas provavelmente mudarão com o tempo. Escolher o TFS é basicamente colocar em jogo, dizendo que "a Microsoft vencerá em todos os aspectos do meu ALM", o que é bobagem. Eu usei o Git com Jira, por exemplo, o que me permitiu atualizar / fechar problemas com base na minha mensagem de confirmação. Na minha experiência (muito com o TFS também), esse é um fluxo de trabalho muito superior.

— 23414 Scott Silvi

1

A barra lateral - mesmo com a integração TFS / Git, você está basicamente dizendo "vamos distribuir VCS para Git, mantendo nosso rastreamento de problemas" - fundamentalmente não é diferente de usar o Git com qualquer outro software de rastreamento de problemas. Portanto, não tenho mais certeza de que o argumento ALM seja válido, dadas as tentativas de flexibilidade da Microsofts (o que aplaudo).

— 23414 Scott Silvi

14

A coisa toda distribuída do Git é realmente muito boa. fornece alguns recursos que os Shelvesets não possuem (no produto atual), como opções de reversão e confirmação local (como o recurso de histórico local do Eclipse ). Você pode aliviar isso usando ramificações de desenvolvedor, mas vamos ser honestos, muitos desenvolvedores não gostam de ramificar e mesclar um pouco. Pediram-me para ativar o recurso antigo de "checkout exclusivo" no TFS algumas vezes com muita frequência (e neguei-o sempre).

Eu acho que muitas grandes empresas estão com muito medo de permitir que um desenvolvedor traga toda a história para um espaço de trabalho local e leve-a com elas (para um novo empregador, por exemplo) ... Roubar um instantâneo é ruim, mas tirar toda uma história é ainda mais problemático. (Não que você não tenha conseguido obter um histórico completo do TFS ) ...

Mencionou-se que é uma ótima maneira de fazer backup, o que é ótimo para código-fonte aberto novamente, onde o mantenedor original pode parar para cuidar e remover sua versão, mas para um plano corporativo isso fica aquém para muitas empresas, pois não há uma atribuição clara de responsabilidade manter backups. E seria difícil descobrir qual versão usar se o 'projeto' principal desaparecer de alguma forma. O que tenderia a nomear um repositório como líder / central.

O que eu mais gosto no Git é a opção Push / Pull, na qual você pode facilmente contribuir com código para um projeto sem a necessidade de ter direitos de confirmação. Eu acho que você poderia usar usuários e prateleiras muito limitados no TFS para imitar isso, mas não é tão poderoso quanto a opção Git. A ramificação entre projetos de equipe também pode funcionar, mas, do ponto de vista administrativo, não é realmente viável para muitas organizações, pois a adição de projetos de equipe acrescenta muita sobrecarga administrativa.

Eu também gostaria de acrescentar às coisas mencionadas na área de controle que não é de origem. Recursos como rastreamento de itens de trabalho, relatórios e automação de compilação (incluindo gerenciamento de laboratório) se beneficiam muito de um repositório principal central. Isso se torna muito mais difícil quando você usa um modelo distribuído puro, a menos que você faça um dos nós à frente (e, portanto, volte para um modelo menos distribuído).

Com o TFS Basic fornecido com o TFS 11, pode não ser muito difícil esperar um TFS distribuído que permita sincronizar seu TFS básico local com um TFS central no TFS 12+. Vou colocar meu voto a favor no uservoice !

— jessehouwing
fonte

Você também estará interessado neste novo recurso oferecido

— jessehouwing

1

use git-tfs. No momento, é muito melhor que git-tf !!! github.com/git-tfs/git-tfs

— Philippe

3

Toda essa resposta está ficando desatualizada rapidamente. A Microsoft adicionou o suporte ao Git ao Team Foundation Service e o suporte ao Git na próxima versão principal do Team Foundation Server.

— Jessehouwing #

1

@ Philippe: Eu tentei os dois. Algumas diferenças: 1) O git-tf é multiplataforma, enquanto o git-tfs é executado apenas no Windows. 2) O git-tfs reescreve as descrições de confirmação quando você "pressiona" para incluir o número do conjunto de alterações, enquanto o git-tf deixa intactos os hashes de confirmação local.

— Joey Adams

@JoeyAdams 1) +1, essa é a única boa razão para escolher o git-tf 2) Você também pode fazer isso com o git-tfs usando o checkincomando (em vez de rcheckin). Mas eu prefiro rcheckin porque é mais a maneira git para fazer as coisas e é por isso que escolhemos para uso git;)

— Philippe

9

Para mim, a principal diferença são todos os arquivos auxiliares que o TFS adicionará à sua solução (.vssscc) para 'dar suporte' ao TFS - tivemos problemas recentes com esses arquivos que foram mapeados para a ramificação errada, o que levou a uma depuração interessante ...

— Paddy
fonte

2

Bom ponto aqui. O Git adicionará a .gitpasta para rastrear todos os detalhes do repositório. O TFS modificará no mínimo o seu .sln(ou é o.csproj arquivos ?) Para colocar o local do repositório remoto.

— CodingWithSpike

5

Esqueci o quanto odiava como o VSS modificaria seus arquivos 'para' você.

— Paddy