É com grande satisfação que a Microsoft torna público algo que os MVPs já sabiam fazia um bom tempo: o TFS agora suporta Git como controlador de versão. O sistema tradicional de controle de versão, agora chamado de Team Foundation Version Control (TFVC), ainda existe, mas o Git agora aparece como uma opção.

Em tempo: o Visual Studio em si, a IDE, também ganhou suporte ao Git. Vou deixar para outra pessoa postar aqui e mostrar como ele funciona. Dado a empolgação do pessoal, não deve demorar muito. Fiquem atentos no rss do blog. É bom deixar claro que nada do suporte do servidor implica na necessidade das ferramentas do Visual Studio. O servidor de Git é um server como qualquer outro, e pode ser usado somente na linha de comando/terminal, de qualquer SO que suporte Git. A Microsoft está deixando extremamente claro que esse não é o Git da Microsoft, mas o Git original, sem adaptações, rodando no TFS.

Como usar?

O Git está nesse momento disponível no TFService, mais conhecido como VisualStudio.com. Vá para tfs.visualstudio.com, e você pode criar sua própria conta gratuitamente, com quantos projetos quiser, e trabalhar em um time de até cinco pessoas pagando absolutamente nada.

Ao entrar na sua área de trabalho, que vai ser algo tipo seunome.visualstudio.com, você verá a opção de criar projeto. Ao lado da tradicional, criaram um botão vermelhão para mostrar que o Git faz parte das opções agora:

Criar projeto com git

Ao mandar criar, você pode trocar a opção, se quiser. Aparece assim:

Criando projeto com git

Além disso, tem toda uma área de apoio pra quem está começando, na própria página, também com bastante destaque:

Suporte ao Git na home

Ao navegar para o projeto criado com git, e clicar na aba Code, eles te avisam que você não tem código algum lá ainda.

Projeto recém criado mostrando info de clone

Notem que eles falam das credenciais. O TFS não suporta SSH, e ao que tudo indica não suportará. Até mesmo o Github tem sugerido, mesmo para clientes Linux e Mac, o uso do HTTPS no lugar do SSH. Eu, no Linux, prefiro SSH, por não ficar demandando senha toda hora, enquanto o cache do Git tem um limite de tempo. Mas vai de cada um.

Vou mostrar aqui o código do Recast (saiba mais sobre o projeto aqui). Ele está público no Github, e foi de onde desenvolvi, até porque queria deploy automático da app pro Azure. Em paralelo eu fui testando o Git do TFS. Sempre que empurrava pro Github, empurrava também pro TFS. Isso ficou fácil, foi só emitir um: “git remote add tfs https://giggio.visualstudio.com/DefaultCollection/_git/Recast“ e depois começar a usar via “git push tfs master”, etc.

Nos meus testes funcionou perfeitamente. Tudo. Criei e apaguei branches, tageei, rebase, etc…

E é legal que as visualizações todas estão funcionando sem problemas, como se esperava. Alguns exemplos (clique para ampliar, setinhas para navegar entre as imagens):

Listando arquivos:

Listando arquivos

Vendo um arquivo (vejam o syntax highlighting):

Vendo um arquivo

Commits e branches:

Commits e Branches

Listando diferença entre os arquivos de um commit (gosto desse visual):

Diff entre arquivos comitados

Comparando duas versões de commits aleatórios:

Duas versões de commits

History de um arquivo (notem que o tamanho da bolinha determina o tamanho do commit, com mais ou menos alterações):

History de arquivo

Aqui as tags de um projeto:

Tags do projeto

E o que eu acho disso tudo?

Eu acho sensacional. Por diversos motivos.

Primeiro porque a Microsoft está ouvindo a comunidade. Sugeri a ideia de suportar DVCS (nem falei de Git), no User Voice. A ideia era a terceira mais votada, e agora foi aprovada (notem a tag Completed na ideia, colocada agora a pouco, apontando pro suporte via link). É a segunda ideia aprovada mais bem votada da história. (Em tempo: vejam os comentários falando mal do DVCS na sugestão da ideia e notem como o medo paraliza as pessoas).

Segundo porque a Microsoft desistiu da ideia do NIH (Not Invented Here), ou seja, nada do que não fosse feito por ela seria bom. Eles estão demonstrando maturidade, já tem tempo, de escolher quais projetos fazer em casa, e quais adotar. Não é a primeira vez. Foi assim com jQuery, Hadoop, e diversos outros, e agora com o Git. Mostra consistência.

Terceiro porque Git é open source. Não bastasse adotar, a Microsoft está contribuindo ativamente no projeto do Git, tendo diversos pull requests aceitos para a principal biblioteca do Git, a libgit2, escrita em C, além de um dos core commiters também trabalhar na Microsoft (Philip Kelley) – aqui um exemplo. Interessante ver a Microsoft atuando, com permissão dos colaboradores atuais, e sendo convidada para ser um deles, em uma biblioteca escrita originalmente pelo Linus Torvalds. Aliás, pra quem não sabe, a Microsoft é a quinta maior contribuidora corporativa no Kernel do Linux. Nada mal pra uma empresa que falam que não gosta de Open Source, né?

Quarto porque o suporte a builds baseados em Git já está funcionando. Falta ainda o build motivado por commit, pra apoiar integração continua, mas imagino que ele venha logo.

E quinto porque Git é incrível, e o TFS vem se tornando uma ferramenta cada vez melhor. Quem me conhece sabe que tenho minhas críticas à ferramenta, mas na versão 2012 a Microsoft atendeu quase todas as minhas necessidades no TFS, com menos burocracia na gestão do projeto, um card wall, kanban, melhorias no build, etc. Nem instalar ele eu preciso mais, está na nuvem, e ainda gratuito pra times pequenos, possibilitando a todos terem seu próprio TFS. Mas ainda me irritava ter que usar um source control centralizado. Não mais. Agora posso ter toda o suporte pra uma excelente gestão do projeto (ágil, sem dúvida), um servidor de build, suporte a testes manuais e labs, e ainda o bom e velho Git. O que mais eu quero? Nada. Suporte pra builds de Linux. Mas isso é outra história, depois falamos disso.

O lançamento do Git aconteceu hoje no ALM Summit americano, que também acontece aqui no Brasil sob o nome ALM Summit Brasil, e é organizado pela Lambda3 (yours, trully). Quem apresentou o Git no TFS foi ninguém menos do que o Brian Harry, o cara que capitaneia o TFS. Ele foi pra Microsoft quando ela comprou o Source Safe, produto que a empresa dele fazia (ou seja, faz tempo), e depois o TFS foi criado, sob sua batuta. Não a toa o TFS tem algumas semelhanças em nomes e conceitos com o Source Safe (checkin, checkout, etc) – mas para por aí, já que é outro produto completamente. E segundo quem estava no Summit, Brian Harry disse: “O Git venceu a guerra do DVCS”. Em vez da Microsoft brigar com o Git e criar o seu DVCS, ela apoiou um projeto da comunidade e do mercado.

Esse lançamento vem em um tempo interessante, ao menos pra mim. Como eu disse, eu sempre esperei algo mais poderoso do source control do TFS, sem nunca ser atendido (até agora). Também sempre gostei do Git. E tenho tido gosto de usar o TFS ultimamente, descontado o source control centralizado. No entando, eu nunca defendi lados. Enquanto isso, alguns diziam que TFS era horrível e que bom era Git (em geral membros da comunidade Open Source + alguns da comunidade Microsoft). Outros diziam que Git era horrível e que bom era TFS (em geral membros da comunidade Microsoft). E agora, como essas pessoas ficam, tendo que conviver com as duas, que agora colaboram perfeitamente? É sempre bom lembrar: use o que gosta, elogie o que gosta. O que não gosta, guarde pra si.

Mais recursos:

Vão lá experimentar. E me contem o que acharam da ideia e da implementação aqui nos comentários.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.