Oito razões para preferir Git ao invés de TFVC
Há um ano atrás escrevi um post com oito razões para usar o TFVC ao invés do Git no TFS. À época, disse que escreveria um post complementar com os argumentos para dar preferência ao Git ao invés do TFVC. Bem, demorou mas chegou a hora. Eis aqui oito razões para preferir o uso de Git ao invés de TFVC num team project do TFS ou do VSTS. Devo dizer que queria muito ir direto ao ponto, mas infelizmente não posso. Isso porque, primeiramente, tenho que fazer uma admissão pública.
Git é melhor que o TFVC. E ponto.
Muita gente perdeu a cabeça quando, no “post-irmão” deste aqui, brinquei que o TFVC era melhor que o Git. Definitivamente a internet tem se tornado cada vez mais um lugar de justiceiros ranzinzas. Bem, para trazer um pouco de felicidade a essa horda de grumpies, está devidamente registrado neste post que o Git é melhor que o TFVC. Ah, uma coisa importante a frisar: a ideia desses posts nunca foi comparar o Git e o TFVC de maneira genérica, fora de um contexto específico. Pelo contrário, a ideia era que o contexto fosse bem específico:
Para um usuário de TFS que vá criar um novo repositório de controle de versão, qual opção escolher? TFVC ou Git?
Viu? A comparação é única e exclusivamente dentro do contexto de usuários do TFS/VSTS. Se você não usa nenhum dos dois, então talvez alguns dos pontos discutidos neste post não sejam tão relevantes. Ainda assim, seus comentários serão bem-vindos! Com isso tudo fora do caminho, acho que finalmente estou livre para falar do que interessa… 
Eis os oito motivos para preferir o Git ao TFVC como repositório de controle de versão no TFS/VSTS:
Padrão de facto para controle de versão
A guerra dos repositórios de controle de versão acabou e o Git venceu. Simples assim. É claro que os outros vão continuar por aí por muito tempo; Subversion, Mercurial, CVS, TFVC, ClearCase, RTC Streams, Perforce e até mesmo SourceSafe (!) ainda estarão por aí por uns bons anos. Mas o futuro chegou e ele se chama Git. Dessa forma, se você não tem nenhum dos motivos citados no post anterior para ficar com o TFVC, este por si só talvez já seja motivo suficiente. Adotar o Git significa dar uma garantia de longevidade para seu projeto que o TFVC simplesmente não tem como oferecer. Ah, se você é um desenvolvedor e ainda não conhece Git, #ficaadica: você está ficando obsoleto mais rápido do que você imagina…
Lingua franca do mundo open-source
O Git nasceu com uma finalidade bem específica: servir como solução de controle de versão para ser usada pelos desenvolvedores do Kernel do Linux – aliás, o criador do Git é o próprio Linus Torvalds. Porém a solução ficou tão bacana e flexível que acabou sendo adotada por outros projetos open-source. Essa adoção por outros projetos OSS começou de maneira tímida mas com o tempo foram substituindo outras opções open-source comumente usadas – Subversion em especial. O grande catalisador da adoção do Git como o formato padrão de repositório de projetos OSS, entretanto, foi o GitHub. O conceito de “rede social para desenvolvedores”, com a hospedagem gratuita de código-fonte para projetos open-source, não era exatamente nova. SourceForge já existia e estava bem estabelecido quando o GitHub surgiu. Porém a experiência de usuário do GitHub superou em muito a oferecida pelo SourceForge e outros sites equivalentes da época. Não demorou muito para ele destronar todos eles (incluindo o também malfadado CodePlex da Microsoft). Eu arriscaria dizer que a maioria absoluta dos projetos open-source, hoje em dia, é hospedado no GitHub. E o que isso tem a ver com usuários de TFS e VSTS? Bem, open-source é algo que sempre foi importante em todas as comunidades de desenvolvimento – mesmo as proprietárias, como era o caso do .NET até há pouco tempo atrás. Mas essa importância vem aumentando a cada dia; basta ver os movimentos todos da Microsoft na direção da abertura do código de diversos de seus produtos, além da integração com soluções open-source. Seus times de desenvolvimento inevitavelmente terão de interagir com projetos open-source mais cedo ou mais tarde. Dominar Git agora – usar Git no dia-a-dia – significa minimizar o atrito que eles sofrerão em suas primeiras incursões por conceitos típicos de projetos open-source baseados em Git e hospedados no GitHub. Além disso, novos desenvolvedores já estarão provavelmente familiarizados com o Git; oferecer um repositório corporativo baseado em Git diminui o tempo que esse dev leva para se integrar ao seu time, comparado com alguém que precisaria se acostumar com TFVC.
Distribuído e descentralizado
Quem trabalha com controles de versão centralizados – como é o caso do TFVC – normalmente morrem de medo de uma queda de rede/internet. Isso porque, se ficarem desconectados, não conseguirão mais versionar seu código-fonte. Um DVCS (distributed version control system), por outro lado, não sofre desse mal. Desenhado explicitamente para suportar cenários desconectados, o Git permite que desenvolvedores façam uma cópia (“clone”) do repositório de controle de versão em suas máquinas individuais. Assim, os commits podem ser feitos em seu próprio computador, sem depender de acesso a um banco de dados centralizado. Uma vez que o conjunto de alterações feitas pelo desenvolvedor esteja pronto para ser integrado ao repositório central, ele “empurra” (“push”) suas alterações. Na Lambda3, por exemplo, isso é particularmente útil. Nossos times de desenvolvimento que atendem a clientes remotos não precisam de uma conexão online o tempo todo com o TFS do cliente para poderem trabalhar. Eles clonam o repositório, fazer seu trabalho desconectados e, assim que estiverem prontos, integram seu trabalho com o resto do time fazendo o push para o TFS do cliente. Ou seja, mesmo que a VPN tenha ficado indisponível por um tempo, eles não deixaram de trabalhar.
Commits frequentes
A conveniência de trabalhar desconectado e de entregar o código apenas quando pronto (testado etc.) permitiu que desenvolvedores que utilizam Git acabassem criando um hábito bastante salutar: Fazer commits frequentes (às vezes na casa das dezenas de commits por dia), registrando pequenos incrementos de código. Dessa forma, revisar suas alterações (e voltar atrás, se necessário) se torna muito mais fácil. Além disso, recursos como amend (a possibilidade de corrigir o último commit, alterando seu conteúdo), rebase (reescrita do histórico de commits) e squash (a combinação de diversos commits em um só) diminuem em muito o medo de se criar vários commits, pois o desenvolvedor tem a liberdade de alterar e ajustar esses commits à vontade, deixando-os “redondinhos” para o momento da integração.
Branching e merging mais simples e eficientes
Quem é que não tem pavor de merges? Garanto a você que todo usuário de TFVC tem 
. Esse é, a meu ver, um dos maiores benefícios que o Git traz em comparação com o TFVC: seu algoritmo de branching e merging é muito mais eficiente que o TFVC, reduzindo consideravelmente a quantidade de conflitos que no TFVC teriam de ser resolvidos manualmente.
Pull requests
Outra funcionalidade muito bacana do Git quando usado dentro do TFS/VSTS, o pull request corresponde, de certa maneira, ao code review do TFVC. É um dos mecanismos mais bacanas para ajudar os times a melhorar a qualidade do seu código, pois estimula o peer review. Na Lambda3, por exemplo, há um acordo na maioria dos projetos de desenvolvimento: nenhum desenvolvedor faz push direto para o branch master. Integrações devem acontecer sempre através de pull requests. Dessa forma, outros desenvolvedores do time têm a oportunidade de revisar o código antes de integra-lo, minimizando o risco de integrar código com problemas. Além disso, a funcionalidade de pull requests oferece várias conveniências como a exibição do status do último build de CI (build quebrado, pull request rejeitado), o histórico de discussões (com as dicas de correções/melhorias de código) e o merge automático (sempre que possível, claro).
Cross-platform
Muitas pessoas ainda veem o TFS/VSTS como uma solução de controle de projetos .NET, mesmo que há anos isso não seja verdade. Porém, ainda que a Microsoft ofereça um _client _cross-platform para o TFVC (conhecido como Team Explorer Everywhere) ele tem suas limitações. Já o Git, por outro lado, é suportado em praticamente todos os sistemas operacionais e está integrado à maioria dos IDEs e editores de texto para programadores – tem até mesmo Git escrito em Javascript! Ao adotar o Git no TFS/VSTS, você facilita a vida dos seus times que trabalham em plataformas não-Microsoft, como por exemplo os desenvolvedores de iOS e Android.
Git Flow
Uma outra queixa comum de usuários de TFVC é “como devo estruturar meu modelo de branches?” Na falta de um modelo padronizado e consistente, cada time “inventa” um modelo diferente de trabalho que muitas vezes mais atrapalha do que ajuda. Já com o Git, você não precisa partir do zero. Ao invés disso, pode usar o processo conhecido como “Git Flow” – um processo simples, eficiente e bem documentado de gerenciamento de branches e de releases para Git. Como todo processo, há os que gostam e os que desgostam. Avalie-o para ver se se adequa ao modelo de trabalho do seu time. Mas é melhor que “inventar” um modelo do zero, dentro de casa. Além disso, são grandes as chances de que novas contratações em seu time conheçam o Git Flow, ajudando de novo a reduzir o atrito inicial do onboarding de um novo membro no time.
O fim do “ame-o ou deixe-o”
Ah, isso é muito legal: Recentemente a escolha por Git ou TFVC deixou de ser algo drástico, do tipo “até que a morte os separe”. Antigamente, ao criar um team project no TFS/VSTS você escolhia um formato de repositório de controle de versão e ficava preso a ele para o resto da vida daquele projeto. Agora, é possível hospedar repositórios Git e TFVC no mesmo team project. Isso oferece mais flexibilidade aos times, que podem escolher o formato de repositório que melhor lhes aprouver. O que achou do post? Não deixe de comentar! Um abraço, Igor
07/03/2016 | Por Igor Abade V. Leite | Em Técnico | Tempo de leitura: 9 mins.
