Git vs Team Foundation Server [fechado]

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

Com o TFS, os repositórios são armazenados num servidor central e os programadores verificam uma cópia de trabalho, que é um instantâneo do Código num ponto específico no tempo. Com o Git, os desenvolvedores clonam o repositório inteiro para suas máquinas, incluindo todo o histórico.

Uma vantagem de ter o repositório completo nas máquinas do seu programador está a redundância no caso do servidor morrer. Outra boa vantagem é que você pode mover sua cópia de trabalho para trás e para a frente entre revisões sem nunca falar com o servidor, o que pode ser útil se o servidor está em baixo ou apenas inacessível.

Para mim, a verdadeira vantagem é que você pode enviar changesets para o seu repositório local sem nunca falar com o servidor ou infligir alterações potencialmente instáveis na sua equipa (isto é, quebrar a compilação).

Para por exemplo, se estou a trabalhar num grande recurso, posso demorar uma semana a codificá-lo e testá-lo completamente. Não quero entrar no código instável a meio da semana e quebrar a Constituição, mas o que acontece se eu estiver perto do fim da semana e acidentalmente bork toda a minha cópia de trabalho? Se não me comprometi o tempo todo, arrisco-me a perder o meu trabalho. Isso não é um controlo de versão eficaz, e a TFS é susceptível a isso.

Com DVCS, posso comprometer-me constantemente sem me preocupar em quebrar o compilar, porque estou a enviar as minhas alterações localmente . Em TFS e outros sistemas centralizados não existe um conceito de check-in local.

Eu nem sequer entrei em quão melhor ramificação e fusão é em DVCS, mas você pode encontrar toneladas de explicações aqui em SO ou através do Google. Posso dizer-lhe por experiência própria que ramificar e fundir em TFS não é bom.

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

As pessoas têm de baixar a arma, afastar-se do parapeito e pensar por um minuto. Acontece que existem vantagens objetivas, concretas e inegáveis para os DVCS que farão uma enorme diferença na produtividade de uma equipe. Tudo se resume a ramificar e fundir. Antes dos DVCS, o princípio orientador era "orar a Deus para que você não tenha que se ramificar e se fundir. E se o fizeres, pelo menos implora-lhe para que seja muito, muito simples." Agora, com DVCS, ramificação ( e fusão é tão melhorada, o princípio orientador é, "Faça-o com a gota de um chapéu. Ele vai lhe dar uma tonelada de benefícios e não lhe causar quaisquer problemas." E isso é um grande impulsionador de produtividade para qualquer equipa. O problema é que, para as pessoas entenderem o que acabei de dizer e estarem convencidas de que é verdade, primeiro têm de investir num pouco de curva de aprendizagem. Eles não têm que aprender Git ou qualquer outro DVCS em si ... eles só precisam de ... saiba como o Git faz ramificações e fusões. Leia e re-leia alguns artigos e posts do blog, levando-o devagar, e trabalhando através dele até você vê-lo. Isso pode levar a melhor parte de 2 ou 3 dias completos. Mas assim que vires isso, nem sequer considerarás escolher um não-DVCS. Porque há realmente vantagens claras, objetivas e concretas para DVCS, e as maiores vitórias são na área de ramificação e fusão.

Original : @Rob, o TFS tem algo chamado " Shelving " que aborda a sua preocupação em comutar o trabalho em progresso sem que isso afecte a construção oficial. Eu percebo que você consulte a central de controle de versão como um obstáculo, mas com respeito à TFS, verificar o seu código para a prateleira pode ser vista como uma força b/c, em seguida, o servidor central tem uma cópia do seu trabalho-em-progresso no caso raro de sua máquina local falha ou é perdido/roubado ou você precisa mudar de marcha rapidamente. As a questão é que os Fe devem ser devidamente elogiados neste domínio. Além disso, a ramificação e fusão em TFS2010 foi melhorada a partir de versões anteriores, e não é claro a que versão você está se referindo quando você diz "... a partir da experiência que ramificar e fundir em TFS não é bom."Disclaimer: i'm a moderate user of TFS2010.

Editar Dez-5-2011: para a OP, uma coisa que me incomoda sobre TFS é que ele insiste em definir todos os seus arquivos locais para "apenas leitura" quando você não está trabalhando sobre eles. Se você quiser fazer uma alteração, o fluxo é que você deve "check-out" o arquivo, que apenas limpa o atributo readonly no arquivo para que a TFS saiba manter um olho nele. É um fluxo de trabalho inconveniente. A maneira que eu preferiria que funcionasse é que é apenas detecta automaticamente se eu fiz uma mudança e não se preocupa/incomodar com os atributos do arquivo em tudo. Dessa forma, posso modificar o arquivo no Visual Studio, ou no bloco de notas, ou com qualquer ferramenta que eu quiser. O sistema de controlo de versões deve ser o mais transparente possível a este respeito. Existe uma extensão Windows Explorer (TFS PowerTools ) que lhe permite trabalhar com os seus ficheiros no Windows Explorer, mas isso não simplifica muito o fluxo de trabalho.

Em cima de tudo o que foi dito (

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

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

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

), o que é correcto, o TFS não é apenas um VCS. Uma das principais características que o TFS fornece é a funcionalidade nativamente integrada de rastreamento de bugs. As mudanças estão ligadas a problemas e podem ser rastreadas. Várias políticas de check-ins são suportados, bem como a integração com o domínio Windows, que é o que as pessoas que executam TFS têm. GUI fortemente integrado com Visual Studio é outro ponto de venda, que apela para menos do que a média mouse and click developer e seu gerente.

Por isso, comparar o Git com o TFS não é uma pergunta adequada. Correto, embora impraticável, a questão é comparar Git com apenas funcionalidade VCS de TFS. Nesse caso, o Git explode o TFS para fora da água. No entanto, qualquer equipa séria precisa de outro ferramentas e é aqui que o TFS fornece um destino de paragem.

Se a sua equipa usar o TFS e quiser usar o Git, talvez queira considerar uma ponte "git to tfs". Essencialmente você trabalha dia a dia usando Git em seu computador, então quando você quer empurrar suas alterações você as empurra para o servidor TFS.

Há um casal lá fora (no github). Eu usei um em meu último lugar (junto com outro desenvolvedor) com algum sucesso. Ver:

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

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

Depois de uma investigação entre os PR e os contras, a empresa com quem estive envolvido também decidiu optar pela 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 a TFS oferece. Se apenas o recurso de controle de versão fosse importante, a escolha provavelmente teria sido GIT. A curva de aprendizagem git íngreme para desenvolvedores regulares pode, no entanto, não ser subestimada.

Veja uma explicação detalhada no meu post TFS como um true cross-technology platform .

A coisa toda distribuída do Git é muito boa. ele dá algumas características que os Shelvesets não têm (no produto atual), tais como opções locais de rollback e commit (tais como o recurso localhistory do Eclipse). Você poderia aliviar isso usando ramificações de desenvolvedores, mas sejamos honestos, muitos desenvolvedores não gostam de ramificar e fundir um pouco. Eu fui convidado a ligar o antigo estilo" checkOut exclusivo " recurso em TFS algumas vezes com demasiada frequência (e negou-o cada e cada tempo). Penso que muitas grandes empresas têm muito medo de permitir que um dev traga toda a história para um espaço de trabalho local e a leve com elas (para um novo empregador, por exemplo)... Roubar um instantâneo é mau, mas tirar uma história inteira é ainda mais problemático. (Não que você não pudesse obter uma história completa da TFS de você queria isso)... É mencionado que é uma ótima maneira de backup, o que é ótimo para o código aberto novamente, onde o mantenedor original pode parar cuidar e remover sua versão, mas para um plano de empresa isso novamente fica aquém para muitas empresas, uma vez que não há atribuição clara de responsabilidade para manter backups. E seria difícil descobrir qual versão usar se o principal 'projeto' desaparecer de alguma forma. Que tenderia a nomear um repositório como líder/central.

O que eu mais gosto no Git é a opção Push / Pull, onde você pode facilmente contribuir com código para um projeto sem a necessidade de ter direitos de commit. Acho que tu ... poderia usar Usuários muito limitados e shelvesets em TFS para imitar isso, mas não é tão poderoso como a opção Git. Ramificar entre projetos de equipe também pode funcionar, mas de uma perspectiva administrativa não é realmente viável para muitas organizações, pois adicionar projetos de equipe adiciona um monte de despesas administrativas.

Eu também gostaria de acrescentar às coisas mencionadas na área de controle Não-fonte. Características como rastreamento de itens de trabalho, Relatórios e automação de construção (incluindo gerenciamento de laboratório) beneficiar muito de um repositório de liderança central. Estes tornam-se muito mais difíceis quando você usa um modelo distribuído puro, a menos que você faça um dos nós liderando (e, assim, voltar para um modelo menos distribuído).

Com o TFS Basic a chegar com o TFS 11, pode não estar longe de esperar um TFS distribuído que lhe permita sincronizar o seu TFS local básico com um TFS central na era TFS 12+. Vou pôr o meu voto a favor disso no uservoice!

Para mim a grande diferença é que todos os arquivos ancestrais que a TFS irá adicionar à sua solução (.vssscc) para 'suportar' TFS-Tivemos Problemas Recentes com esses arquivos terminando mapeados para o ramo errado, o que leva a alguma depuração interessante...