O GIT é muito utilizado no mundo da programação.
Com ele, conseguimos ter um controlo de versões do código produzido. Ao longo do tempo de desenvolvimento, cada programador pode incluir pedaços de novo código e alterações sobre uma branch principal. Estas adições são associadas a uma versão, sendo possível navegar entre elas, reverter código, entre outras possibilidades.
O Git foi criado em 2005, pelo mesmo homem responsável pela criação do Kernel do Linux, Linus Torvalds.
O Git é uma das ferramentas de controlo de versões mais usadas. Milhões de projetos assentam o seu versionamento com esta ferramenta.
Podemos usar o Git de forma totalmente gratuita, em vários sistemas operativos.
Características do Git
O controlo de versões Git, segue uma abordagem peer to peer, seguindo o sentido inverso de outros sistemas como o Subvision (SVN), que segue uma abordagem de cliente-servidor.
Uma das principais vantagens do Git, é que permite uma infinita lista de ramificações do código, permitindo uma criação, fusão e exclusão dessas ramificações de forma fácil e sem despender demasiado tempo.
Também conta com um sistema de operações atómicas. Isto faz com que as operações apenas podem ter sucesso ou não, e assim não efetua nenhuma alteração direta. Isto é algo bastante importante, pois desta forma permite que o repositório se mantem estável.
Uma das áreas mais importantes do Git, para alguns, é certamente a possibilidade que ele dá de fazer code review. Desta forma os programadores podem alterar o seu código e receber feedback antes de o juntar a branch principal.
Utilização do Git Flow
O Git Flow é basicamente um fluxo feito dentro do controlo de versões, desde uma branch com novo código, e quais os estágios por onde essa branch vai passar.
Cada empresa ou projeto usa o seu próprio fluxo. É recorrente ver projetos pessoais, onde o desenvolvedor usa apenas uma branch principal, e aplica todos os commits nela. Isto não é um mau sistema quando trabalhamos sozinhos. Desta forma é fácil controlar e gerir todo o projeto. As coisas tornam-se mais complicadas quando trabalhamos com mais do que um contribuidor.
Se aplicarmos aqui também as questões de testes de qualidade, podemos implementar um fluxo de branch. Isto vai ajudar que os testes de qualidade, não sejam feitos sobre branch de desenvolvimento, que sofrem constantes alterações e instabilidades.
Abaixo fica uma imagem de um git flow de exemplo:
Num sistema de testes de qualidade e testes de aceitação, é importante isolar o código de cada um. Assim o fluxo de testes de qualidade, segue logo após o desenvolvimento e testes feitos pelo programador na branch local, que mais tarde é integrada na branch de desenvolvimento. Esta branch de desenvolvimento, é onde todos os programadores adicionam os seus códigos feitos localmente, por meio de merge. Assim que são adicionados a branch de desenvolvimento, devem ser executados testes pelos programadores, de forma a garantir que a branch se encontra estável.
Após isso, a branch de desenvolvimento é junta, por meio de merge, à branch de qualidade.
Aqui já temos dois ambientes. O ambiente de desenvolvimento e o ambiente de qualidade. No ambiente de qualidade, é ondes os Testers iram efetuar testes de qualidade no código previamente criado pelos programadores. Várias features serão testadas.
Mais tarde depois destes testes, serão então incluídas as features do ambiente de qualidade (ou branch de QA) no ambiente de Pré-Produção (ou branch de preprd). Neste ambiente, o negócio efetua a sua aceitação das features por ele requisitado, para que mais tarde sejam adicionadas a produção (ou branch de master).
Como disse mais tarde, este fluxo pode ser alterado consoante a necessidade de cada projeto ou empresa.
No meio de todo o fluxo, o ambiente de qualidade pode apresentar problemas nas features, o que acaba por ser resolvido por meio de um bugfix sobre o ambiente de desenvolvimento. Após correção, o fluxo reinicia, passando a nova correção até qualidade para que seja novamente testado. Na aceitação também podem ser encontrados bugs, o que implica a sua correção em desenvolvimento, nova passagem por qualidade e adição a pré-produção para nova aceitação.
As coisas mudam um pouco em produção. Quando um problema ou bug é encontrado já neste ambiente, o mesmo deve ser resolvido como hotfix, e diretamente adicionado a produção, não passando por qualquer outro ambiente. Esta correção, será transposta da branch de master (produção) para a branch de desenvolvimento (ambiente de desenvolvimento) por meio de merge. Assim a branch de desenvolvimento será atualizada com a correção efetuada para progredir o fluxo normal de desenvolvimento, testes e aceitação.
É de extrema importância que a branch de desenvolvimento esteja sempre atualizada o mais possível. Pois através desta branch que novos desenvolvimentos e features são criados. Desta branch nascem diversas ramificações que são mais tarde adicionadas a ela.
Assim sendo:
Feature: Para novos desenvolvimentos.
Release: Para finalizar a release.
Bugfix: Para resolver problemas encontrados nos ambientes de qualidade, onde são efetuados testes as features.
Hotfix: Para resolver bug e problemas que foram encontrados e reportados em produção.
Conclusão
Este artigo é um pontapé de saída para mais uma serie aqui no blog. Desta vez vamos falar mais sobre o Git, como os comandos que podemos usar para seguirmos um Git flow. Vou também apresentar outras ferramentas que podemos usar juntamente com o Git, mas de uma forma mais “amigável”.
Podem também acompanhar as nossas series de Laravel e PHP aqui no Blog.
