Git Parte 1: Como Surgiu a Ferramenta de Controle de Versão Mais Usada no Mundo

Essa é uma série de artigos que contam a forma como eu venho estudando e aprendendo sobre Git.

O Git não é uma ferramenta 100% intuitiva, e até hoje não encontrei um ser humano que não tenha uma relação de amor e ódio com a ferramenta. E não importa quanto tempo de carreira você tem, todo mundo  ̶f̶a̶z̶ ̶m̶e̶r̶d̶a̶  comete erros! E está tudo bem desde que você aprenda com eles.

Nem sempre você vai aprender de primeira, mas ao passo que você vai errando, estudando e usando a ferramenta (principalmente usando), as coisas vão ficando menos complicadas.

Você aprende como resolver os problemas e começa a entender o que está fazendo. Sinto que a maior parte dos meus erros foi por executar comandos porque eu “tinha” que executar. Não porque eu sabia exatamente o que estava fazendo e ou o porquê de usá-los.

Ano passado joguei a ideia desse artigo no meu twitter e perguntei no que as pessoas também sentiam dificuldade, e durante o ano fui estudando e procurando entender os conceitos para criar alguns artigos. Foi demorado, cheio de erros e ainda tenho que aprender muita coisa. Mas agora que entendi melhor alguns conceitos que usei durante o ano, vou conseguir me aprofundar nas bases. 

Histórico e motivação na criação do Git

Toda a história da criação do Git se dá em torno do Kernel do Linux. Ele e seu versionamento foram mantidos durante muito tempo no Bitkeeper, mas a empresa por trás dele, a BitMoover, resolveu ir para uma linha de comercialização do licenciamento de acesso ao software.

Por um tempo, ela permitiu que os desenvolvedores do kernel do Linux usassem a versão gratuita (Freeware), mas um dos mantenedores, Andrew Tridgell, desenvolveu uma versão open source do client, uma ferramenta que poderia trabalhar com o código fonte armazenado no BitKeeper. Porém, a BitMoover ficou extremamente insatisfeita e considerou como violação da licença e engenharia reversa a criação desse client.

Após meses de negociação, esse acesso gratuito foi revogado e surgiu a necessidade da criação de algo que não só substituísse. Mas fosse melhor que o Bitkeeper. Linus e todas as pessoas que mantinham o Kernel começaram a busca, mas nenhuma das opções de controle de versão descentralizadas disponíveis atendiam às necessidades. 

Nasce, então, o Git com a proposta de resolver a necessidade de um sistema de distribuição descentralizada, e que seguisse a filosofia de software livre, assim como o Linux, e sem se preocupar em ficar preso a uma ferramenta proprietária que de um dia pro outro os criadores resolvessem comercializá-lo. 

Visto de um ângulo técnico, o Git é uma ferramenta semelhante ao Bitkeeper por trabalhar de forma distribuída e uma coisa que acho interessante é que grande parte do flow que conhecemos no Git, veio do flow aprendido com o uso do Bitkeeper. Porém, mesmo com essa semelhança a ideia nunca foi ter um clone.

Quando foi criado, a pretensão era resolver exclusivamente o problema relacionado ao Kernel do Linux. Mas hoje o Git se tornou uma das ferramentas mais utilizadas no mundo inteiro para controle de versão.

Sistemas de controle de versão

A melhor forma de eu entender sobre a importância do versionamento foi através de projetos que eu desenvolvia acompanhando algum curso ou artigo. E que costumava manter somente na minha máquina. Tive uma situação em que estava estudando à noite e tive dificuldade em um bug de versão de alguma lib. Como não consegui resolver na hora acabei deixando pra ver depois. Volto quatro dias depois e não tinha ideia do que estava fazendo, como tinha feito e nem o motivo. Isso seria bem mais fácil de entender se eu tivesse versionado o que estava fazendo. Porque voltar para um estado no qual a aplicação ainda funciona é bem mais fácil do que ter que reescrever tudo o que você fez. 

Nesse ponto, é importante entender a necessidade de um sistema de controle de versão e, o que acho fundamental,é termos em mente que ele é o responsável por gravar todas as alterações feitas, e além disso, precisa permitir que todas as alterações feitas ocorram paralelamente e não comprometam o andamento do projeto.

Antes falamos sobre o fato dos mantenedores do kernel do linux optarem por um sistema de controle de versão distribuído, lembra? Os sistemas de versionamento podem ser classificados como distribuídos ou centralizados.

Fonte: Imgur

À partir dessa imagem, conseguimos ver algumas diferenças e o que chama mais atenção — e o que eu acredito que é importante focar sem entrar tanto em partes técnicas — é o que mais diferencia: a forma como trabalhamos com eles e também o ambiente local que o Git nos proporciona, dando uma cópia completa do repositório. Apesar de alguns fluxos terem o mesmo nome, eles funcionam de formas distintas.

Conversando com pessoas aqui da Taller (inclusive, estamos contratando pessoas desenvolvedoras de software 😉 ) que tiveram experiência com centralizados e distribuídos, senti que as maiores vantagens do modelo distribuído foram:

Você conseguir diminuir impactos com ambiente local bem mais seguro e menos complicado de atualizar seu branch com o que está sendo feito pelo seu time no branch master(em sistemas centralizados é branch trunk);

Os deploys eram feitos um de cada vez, e com o modelo distribuído você não precisa criar filas para enviar seu código para produção;

Não depender de ninguém com um acesso específico para criar seus branches;

A possibilidade de enviar pequenas partes de código em commits separados, sem aqueles pushes enormes e com alteração de diversos arquivos e todo o trabalho em fazer backup para conseguir voltar para um estado em que a aplicação funcionava. E não menos importante: sem causar duplicação de arquivos.

Esse último exemplo me lembrou muito o que as pessoas falam sobre commits com alterações em muito arquivos e, com certeza, você já viu algum meme ou alguém falando sobre o quão doloroso isso é para quem está fazendo code review, por exemplo. Mas imagine-se em um cenário onde todo commit feito era um push pro servidor.

As pessoas costumavam fazer commits gigantes de alterações porque o commit era basicamente nosso git commit + git push. Ele não armazenava sua alteração para você enviar depois, como podemos fazer com o Git. O processo de desfazer algo era bem pior do que temos hoje. Acredite. No Git o comando commit funciona como algo que “separa suas alterações” em pequenos pedaços. E você só envia para o repositório após executar o comando push.

.

A parte interessante de saber o histórico e como as coisas eram feitas no passado, é entender o motivo delas resolverem problemas hoje. E também entender o que está por vir. Existem ferramentas surgindo no mercado e uma delas é o Pijul, que tem como premissa ser rápido, amigável ao usuário e realmente distribuído (sendo bem simplista, a base teórica por trás dele é de Teoria das Categorias, mas não tenho propriedade para falar sobre isso ainda).

Não sabemos se o Git ficará para sempre no mercado, mas é importantíssimo aprendermos sobre como ele funciona, não só para trabalhar, mas também para poder participar de projetos open source. Além disso, tem duas talks do Linus falando sobre o Git e vou deixar os links aqui e aqui pra você assistir, infelizmente estão em inglês, mas são riquíssimas e você pode acompanhar pelo tradutor automático.

Nos próximos artigos, vou mostrar como trabalhamos com o Git aqui na Taller e como resolvemos nossos problemas com ele. Um abraço e até mais ver. Se falei alguma bobagem, me conta no meu twitter e bora aprender juntos!