Git: Controlo de Versões para Pequenos e Grandes Projectos

O Git é um sistema de controlo de versões distribuído, gratuito e open-source, desenvolvido originalmente pelo Linus Torvalds, o criador do kernel do sistema operativo Linux, e actualmente é mantido pelo Junio Hamano juntamente com outros quase 300 colaboradores voluntários.

Comparado com outros sistemas de controlo de versões tradicionais, o Git diferencia-se por ser extremamente rápido, por simplificar o desenvolvimento de software de forma não-linear, onde podemos trabalhar em paralelo em diferentes funcionalidades das aplicações que desenvolvemos e então escolher quais funcionalidades devem fazer parte de cada versão da aplicação conforme o nosso fluxo de trabalho, e principalmente por ser um sistema distribuído bastante versátil e adequado para projectos de qualquer dimensão.

Outra grande vantagem do Git, é possuir versões para Windows, Linux e Mac OS X, o que facilita muito o controlo de versão de aplicações desenvolvidas em diferentes plataformas. Hoje em dia é muito comum uma mesma empresa desenvolver aplicações em .NET no Windows, outras em Java no Linux, e ainda outras para iPhone no Mac OS X, e poder utilizar uma única ferramenta para controlo de versão de todas as aplicações desenvolvidas na empresa, é excelente!

Neste artigo, vou explicar o funcionamento do Git e as principais diferenças entre os sistemas de controlo de versões centralizados e distribuídos, como instalar e configurar o Git no Windows, e os principais comandos que precisa conhecer para começar a utilizar o Git no dia-a-dia.

Centralizado vs Distribuído

O Subversion (SVN), o Visual Source Safe (VSS), o Team Foundation Server (TFS), e muitos outros, são todos sistemas de controlo de versões que funcionam de forma centralizada, isto é, existe sempre um computador central (servidor) que contém toda a história dos projectos com todas as inclusões e alterações que foram feitas pelos programadores desde o momento em que o projecto foi incluído no sistema de controlo de versões (geralmente no início do projecto) até a versão mais recente, e cada programador tem apenas uma versão da aplicação em seu próprio computador, normalmente a mais versão recente.

Dessa forma, os programadores estão sempre dependentes do servidor para guardar (check-in) alterações que desenvolvem em seus computadores, bem como para obter as alterações desenvolvidas por outros membros da equipa:

Git: SCM centralizado

Assim, efectuar o controlo de versões com sistemas centralizados é geralmente mais lento, pois todas as operações (check-in, check-out, etc.) necessitam de comunicação com servidor central, que pode estar a apenas alguns metros de distância, como pode estar em outra cidade ou país. Além disso, torna-se impossível controlar versões quando se está desconectado da rede onde encontra-se o servidor central, o que pode ser um problema quando é preciso trabalhar fora das instalações da empresa e não há possibilidades de conectar-se remotamente à rede da empresa, por exemplo nas instalações de um cliente ou em viagens.

Controlo de Versão Distribuído

Num sistema de controlo de versão distribuído como o Git, não existe propriamente um servidor central. Cada programador tem uma cópia completa de toda a história dos projectos em sua própria máquina e pode controlar a versão de ficheiros e conteúdos de ficheiros localmente sem depender de um servidor e, somente quando achar apropriado, pode partilhar as suas alterações com outras pessoas da equipa e/ou receber alterações efectuadas por outros membros da equipa.

No Git, cada conjunto de alterações efectuadas em ficheiros ou conteúdos de ficheiros é chamado de commit, e conforme o programador implementa novas funcionalidades nas aplicações que está a desenvolver, vai efectuando diferentes commits que ficam guardados no seu próprio computador sem precisar depender de um servidor.

Uma vez que cada membro da equipa possui uma cópia integral de toda a história dos projectos, um programador que queira partilhar os seus commits recentes com outro colaborador, pode enviar directamente os commits para este colaborador (push), ou ainda, pode permitir que o outro colaborador obtenha os commits a partir de seu próprio computador (pull), tudo sem precisar comunicar-se com um servidor central.

Git: não é necessário servidor central

No entanto, ao trabalhar em equipas com várias pessoas, ao invés de cada pessoa comunicar-se individualmente com outra para enviar/receber commits, é normal existir um sítio comum onde os elementos da equipa enviam os seus commits para que sejam partilhados com o restante da equipa, sendo este sítio comum normalmente conhecido como servidor de integração.

Git: servidor de integração

À primeira vista, este sítio comum se parece muito como o servidor central dos sistemas de controlo de versões centralizados, mas em realidade é bem diferente, pois é apenas mais um computador com uma cópia de toda a história dos projectos, assim como é o computador de qualquer outro membro da equipa. O servidor de integração é apenas uma convenção social entre os participantes da equipa, de forma a facilitar a partilha das alterações entre as várias pessoas.

O importante a destacar é que nenhum membro da equipa está directamente dependente ou conectado ao servidor de integração. Todos trabalham de forma desconectada em seus computadores, onde efectuam diversos commits que são gravados localmente, e só utilizam o servidor de integração para partilhar seus commits recentes com o restante da equipa, quando/se quiserem.

Git: servidor de integração descentralizado

Dessa forma, as funcionalidades que devem ser partilhadas com toda a equipa, podem ser enviadas (push) para o servidor de integração e os membros da equipa podem obter (pull) essas alterações quando desejarem, assim como funcionalidades que não ainda não estão prontas para serem partilhadas com toda a equipa, podem ser partilhadas apenas entre as pessoas envolvidas no desenvolvimento dessas funcionalidades.

Importante: Algumas ferramentas de controlo de versões centralizado, como por exemplo o Team Foundation Server (TFS), permitem accionar uma opção para trabalhar de forma desconectada do servidor, para então mais tarde (quando for possível conectar-se ao servidor central) enviar as alterações. Isto não é a mesma coisa que que trabalhar num sistema distribuído, pois neste caso não será possível efectuar commits no próprio computador, enquanto efectua diferentes alterações no código, ou seja, a ferramenta não permite gravar diferentes conjuntos de alterações (commits), para depois enviá-los para o servidor. Se trabalhou em funcionalidades diferentes, não conseguirá (facilmente) distinguir quais ficheiros/conteúdos correspondem a cada funcionalidade que trabalhou enquanto estava desconectado, e provavelmente irá enviar um único commit para o servidor central com todas as alterações, e estará a usar o sistema de controlo de versões de forma pouco eficiente.

Publicado na edição 29 (PDF) da Revista PROGRAMAR.