Além do Git: Uma Breve Jornada por Controle de Versão

O controle de versão é um alicerce fundamental no desenvolvimento de software. Ele nos permite rastrear mudanças, colaborar de forma eficiente e reverter erros com facilidade. A história do controle de versão remonta aos lendários Laboratórios Bell — os responsáveis por outras coisinhas mais como o Unix, a linguagem C, o transistor e, em grande parte, toda a computação como a conhecemos — aonde em 1972 foi desenvolvido o Source Code Control System (SCCS), uma ferramenta inovadora para rastrear alterações individuais em cada arquivo.

Ainda muito antes do Git dominar o cenário, existiram outras ferramentas importantes. O CVS (Concurrent Versions System) e o SVN (Subversion) foram amplamente utilizados, representando avanços significativos em relação à edição manual de arquivos. No entanto, essas soluções eram centralizadas, o que apresentava diversas limitações.

Em um sistema de controle de versão centralizado, existe um servidor que armazena o repositório principal do projeto. Todos os desenvolvedores trabalham com cópias locais dos arquivos, mas precisam se conectar a esse servidor central para sincronizar as mudanças. Isso implica em um ponto único de falha: se o servidor central cair, ninguém consegue sincronizar o trabalho. Além disso, para realizar qualquer operação que envolva o repositório é necessária uma conexão constante com o servidor, dificultando o trabalho de desenvolvedores offline ou com conexões instáveis.

Adicionalmente, nesses sistemas, o uso de ramificações era uma operação custosa e geralmente não incentivada, não sendo inerente à centralização em si, mas sim ao design dessas ferramentas. Então, surgiu o Git, o primeiro sistema de controle de versão distribuído verdadeiramente popular. Essa mudança representou um enorme salto em frente. O Git utiliza um grafo de Merkle (a mesma estrutura de dados usada no blockchain do Bitcoin) para rastrear as alterações no código-fonte de forma incrivelmente eficiente.

A natureza distribuída do Git, aliada à sua capacidade de gerenciar ramificações e mesclagens complexas, o tornou ideal para o desenvolvimento do kernel Linux. Criado por Linus Torvalds, o Git permitiu o desenvolvimento no estilo "bazar", descrito no famoso ensaio "A Catedral e o Bazar" de Eric S. Raymond.

Enquanto outros sistemas Unix já existiam, o Linux se destacou não necessariamente por ser tecnicamente superior, mas por causa do Git. Ele viabilizou um modelo de desenvolvimento colaborativo massivo, onde inúmeros desenvolvedores contribuem de forma descentralizada. O Git permitiu que o Linux prosperasse no estilo bazar, com uma hierarquia de colaboradores e a capacidade de Linus Torvalds selecionar as melhores contribuições.

O fluxo de trabalho do kernel Linux, um exemplo clássico de projeto com milhares de colaboradores, utiliza um modelo conhecido como "Ditador e Tenentes". Nesse modelo, diversos gerentes de integração, chamados de "tenentes", são responsáveis por partes específicas do repositório. Todos os tenentes se reportam a um único gerente de integração, o "ditador benevolente" (no caso do Linux, Linus Torvalds).

Ironicamente com o tempo, surgiram plataformas como GitHub, GitLab e Bitbucket que oferecem funcionalidades como hospedagem de repositórios, gerenciamento de issues e revisões de código, mas também centralizam o uso do git em único do repositorio assim como nos antigos modelos.

Também ironicamente, muitas projetos que utilizam Git em um modelo que se assemelha mais a uma "catedral", que adotam uma abordagem baseada em confiança, onde desenvolvedores confiáveis têm permissão para enviar mudanças diretamente para o repositório central, sem a necessidade de um fluxo de "ditador e tenentes". E no geral não existem interferincias nas decisões tomadas por aqueles que tem acesso de escrita ao repositórios.

Essas duas abordagem contradizem a natureza distribuída do Git e, em muitos casos, não apenas deixam de aproveitar todo o seu potencial, que o tornaram a ferramenta de fato para controle de versão, como também cria outros problemas que nem deveriam exister em priemiro lugar. Um exemplo comum disso é a necessidade constante de usar git stash, git pull e git stash pop para sincronizar mudanças antes de um git push.

Existem alternativas distribuídas ao Git, que inclusive utilizam a mesma estrutura de dados permitindos ramificações eficientes, mas que são muito mais adequadas para o desenvolvimento centralizado. Como o Mercurial, criado para apoiar o desenvolvimento do Firefox, ou o Fossil, criado para o SQLite, apenas dois exemplos notáveis. A lição aqui é que o Git é uma ferramenta poderosa, mas nem sempre é a solução ideal.

Ao escolher um sistema de controle de versão, é importante considerar as necessidades do projeto e o estilo de desenvolvimento adotado. A grande maioria dos projetos se assemelha muito mais ao Firefox ou ao SQLite do que ao Linux. Portanto, da próxima vez que você pensar em controle de versão, lembre-se: existe um mundo além do Git. Git nem sempre é a resposta. E, na maioria das vezes, o GitHub definitivamente não é a resposta, a menos que você esteja trabalhando em um projeto de código aberto e buscando contribuições.