Oito razões para preferir Git ao invés de TFVC

Criar team project com Git

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… Smiley piscando 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 Alegre. 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

Autor: Igor Abade

Igor Abade V. Leite (igoravl@mvps.org) é Microsoft MVP (Most Valuable Professional) de Visual Studio ALM desde 2006. Palestrante em diversos eventos da comunidade de desenvolvimento de software (TechEd Brasil, The Developers’ Conference, DevOps Summit Brasil, Agile Brazil, Visual Studio Summit, QCON e outros), é também autor de artigos em revistas e sites como o MSDN Brasil. Desde março de 2011 é um dos sócios da Lambda3, uma consultoria especializada em ALM, desenvolvimento de software e treinamentos. Visite seu blog sobre VS ALM em http://www.tshooter.com.br/ e siga-o no Twitter @igorabade.

11 pensamentos em “Oito razões para preferir Git ao invés de TFVC”

  1. Já trabalhei com ambos (TFS e Git), reconheço que o Git tem algumas vantagens, só não sou fan-boy de nenhum deles (como deixou transparecer o autor), mas depois que eu li que Commit local é uma vantagem… parei de ler o resto do artigo!
    E se seu HD for pro espaço???

    1. Que pena que você parou a leitura do artigo na metade… Seria bom ter seu feedback sobre o resto do post.

      Sobre “e se seu HD for pro espaço?” – bem, isso não afeta apenas o Git, mas qualquer arquivo que você tenha no seu computador. Se você tiver um workspace enorme no TFVC e não tiver feito checkin vai perder dados da mesma forma, não?

      Meu ponto foi: com commits locais é possível ter histórico local, sem depender do servidor para manter o histórico. Qualquer usuário de Git que já tenha feito um Amend ou ou Rebase sabe o valor disso. Em momento algum disse que os dados não deveriam ser “pushados” (palavra horrível, eu sei) para o servidor. Acho que ter parado de ler na metade pode ter comprometido sua interpretação do que escrevi.

      Quanto ao autor ser fan-boy… Bem, não sei de que autor você está falando, mas certamente não é deste que vos escreve! 🙂

      1. Gostaria de deixar o meu comentário… Eu li o post inteiro, doeu muito meus olhos, mas eu li até o fim. Claro, concordo com algumas vantagens do Git como, commits locais e a gestão de branchs, mas dizer que o merging do git é superior? Eu não vi o Git fazer merge linha a linha no arquivo, isso facilita muito quando se tem o time trabalhando com arquivos compartilhados, o que acontece no Git quando um mesmo arquivo foi alterado por mais de 5 devs e afetou por muitas vezes a mesma linha do mesmo arquivo? como unir isso em uma sequencia lógica? Eu sei que o TFS te dá uma ferramenta perfeita para incluir as linhas na posição que você quiser de maneira simples e fácil, você conhece bem isso.

        Concordo com o Edjlle, sobre o “e se seu HD for pro espaço?”, você perde todo o seu trabalho junto com o resto dos arquivos do HD, e concordo com você no caso do TFS que poderia perder também, mas se o membro do time for alguém precavido e efetuar um check-in todos os dias e até mesmo um Shelve de hora em hora, ele praticamente elimina a possibilidade de perder qualquer coisa do trabalho que fez. Em ambientes desastrosos, nem Workstations e nem servidores escapam, então entramos em estrategias de backups, outro assunto.

        Agora um dev que mantem o hábito de usar o commit local e aquele trabalho fica ali no HD local por dias, ele corre um risco seríssimo, pior se for notebook que pode ser roubado. Portanto, vimos que uma boa prática é essencial para ambos os ambientes. Acho que todo e qualquer ambiente de versionamento tem que ter dos dois mundos, poder trabalhar off-line e on-line, coisa que o TFS faz assim como Git só que de jeitos diferentes, você sabe disso, só desligar do servidor e trabalhar sem estar conectado, voltou a ter internet, rede ou conexão que seja, só conectar novamente no servidor e fazer o check-in.

        Já usei os dois ambientes, sou um usuário iniciante no Git e no TFS bem mais avançado e vejo que os dois são bons mas com essas pequenas diferenças que eu considero melhor no TFS, mas dou toda razão de usar Git em ambientes 100% open source, não tem porque usar TFS mas em um ambiente hibrido Microsoft e Open Source, use TFS e seja feliz.

        1. Alex, obrigado pelo comentário. Desde o começo, a ideia de escrever dois posts se contrapondo (Git x TFVC e TFVC x Git) sempre foi a de prover insumos para que as pessoas pudessem avaliar e decidir por conta própria – e não induzir a uma escolha, seja ela qual for.

          A verdade é que as duas escolhar têm seus prós e contras, e o peso de cada um dos argumentos (contra ou a favor) varia de time para time. O mais bacana é quando pessoas como você comparam seu histórico e sua realidade com os recursos que cada ferramenta oferece, ponderam e então tomam uma decisão embasada.

          Só de conseguir a participação de vocês neste tipo de discussão já me leva a crer que alcancei meu objetivo! 😉

        2. Gente, sobre o cenário off-line, vocês não estão vendo ver a vantagem do Git. Não importa se o usuário tem o hábito de fazer check-in ou push frequentemente, ou se HD vai para o espaço ou não. Temos que avaliar ambos os versionamentos num mesmo cenário de indisponibilidade do servidor de versionamento:

          Imagina que você está no cliente apresentando um projeto de manhã e ele pede uma correção e duas melhorias no sistema. Pra uma das melhorias requisitadas você precisa fazer uma POC em cima do sistema pra ver se é possível fazer o que ele quer, e a outra melhoria o cliente quer trocar a cor de um botão que hoje é cinza, mas ficou na dúvida se é melhor trocar pra vermelho ou pra laranja.

          Por qualquer motivo você vai ficar o resto do dia no cliente, e sabe que consegue fazer a correção, a POC e a troca da cor do botão em 4 horas. Com Git você vai poder criar 4 branches na sua máquina: Uma pra correção, outra pra POC, outra pro botão laranja, e outra pro botão vermelho.

          Ai no final do dia você apresenta tudo pro cliente e faz o merge das branches (Correção + POC (Se funcionou) + Cor do Botão escolhida) e gera assim a versão final do código sem precisa reescrever nada.

  2. Gostei do post.
    Eu gerencio um repositório relativamente grande no tfvc e confesso que o assumi sem muito conhecimento, fui aprendendo quebrando a cabeça, e “inventei” o esquema de branchs. E cara… que dor de cabeça, o pessoal vai dando checkin no branch master e eu tenho um branch de “produção” e vou mesclando os checkins feitos no master para esse de produção para fazer os deploys. O merge é muito chato, tem checkins que não podem ir, daí tem que pular eles, e as vezes o zezinho tocou no mesmo arquivo do juquinha e como eu mesclei só o checkin do segundo, o código quebra… coisa de louco

    Estou pensando em mudar para o git e trabalhar com pull request para filtrar mais essa baderna, acha um caminho interessante?

  3. Olá Igor tudo bem? Sou seu ex-aluno da Ka Solution 2009. Seu post foi Sensacional! Esse post foi primordial para eu começar um novo projeto. Eu estava acostumado com SVN e ja passei por alguns problemas com ele e para esse novo projeto eu não queria utilizar mais SVN. comecei a pesquisar sobre TFVC e Git ja que eu nunca havia utilizado nem um e nem outro. Seu posto foi definitivamente tudo o que eu queria saber. Agora é mão na massa e dar uma estudada no Git para poder aproveitar bem seus recursos!!! Muito obrigado Igor. Grande abraço.

  4. E aí Igor beleza?

    Já trabalhei com os dois e posso afirmar sem sombra de dúvida que o Git é muito superior ao TFS. Mas bota muito superior nisso. Ja perdi código no TFS, por problemas no servidor, e isso não ocorreria no Git.

    O merge do Git resolve praticamente tudo automático. Hoje quase não perco tempo fazendo merge, antes chegava a perder boa parte do dia só com isso. Tudo era praticamente tudo manual.

    A sensação que tenho usando o Git com o GitHub é que hoje ando de Ferrari e antes andava de Fusca.

Deixe seu comentário!