Este artigo abordará o conceito sobre a metodologia de trabalho e organização do Git Flow, além de apresentar de modo prático suas aplicações, comandos, situações, vantagens e desvantagens de se utilizar esta metodologia.

O Git Flow é uma ótima forma de organizar o repositório Git de um projeto, desde que seja aplicado da maneira correta e seguindo todos os critérios e processos estabelecidos pela metodologia.

Manter em ordem os processos do Git Flow talvez seja o maior desafio desta ferramenta. Este artigo abordará todo passo a passo desde a criação e evolução de um projeto utilizando Git Flow baseado em situações reais.

Introdução

Com o crescimento e escalonamento das aplicações e processos de desenvolvimento de software no mundo, um dos grandes desafios para manter a integridade do código e permitir que pessoas trabalhem de forma colaborativa no mesmo projeto, foi a criação de ferramentas de controle de versão e repositório.

Existem diferentes opções de ferramentas de controle de versão disponíveis no mercado. Para o objetivo deste artigo, estudaremos a principal ferramenta utilizada por desenvolvedores no mundo todo, o Git.

Existem vários termos que compõem o universo Git, como Git Hub e Git Flow, cada qual com a sua importância dentro do que hoje é a ferramenta como um todo. É importante entender onde cada um se encaixa dentro do que é o Git, qual a importância e diferenças entre as várias versões disponíveis no mercado, e como adaptar seu trabalho a um modelo de repositório aceito mundialmente hoje, conhecido como Git Flow.

Será realizado a definição, o passo a passo para a implementação correta do modelo aplicado no Git, bem como os problemas que a plataforma e o Git Flow podem apresentar, para que seja possível identificá-los ou até mesmo evitá-los.

O que é Git?

O Git é um versionador de arquivos utilizado para controlar a evolução e a alteração de todo o conteúdo de um projeto. Auxilia no gerenciamento do conteúdo produzido dando suporte para analisar tudo o que está sendo criado pela equipe, além de fornecer o controle sobre as versões lançadas e todo tipo de alteração dos arquivos envolvidos no projeto. Mesmo um projeto sendo realizado por uma equipe grande é perfeitamente possível ter o controle através do Git.

O Git ficou conhecido principalmente pelo seu desempenho. É possível gerar um Release para produção em muito pouco tempo de processamento. Apenas alguns segundos são necessários para o Git produzir um pacote pronto para ser colocado em produção. Tarefa tal que seus concorrentes na época, 2005 aproximadamente, não eram capazes de fazer.

Baseado em suas branches, o Git é capaz de fazer o controle e versionar todo o código fonte produzido. Mas é válido lembrar que o Git não faz milagre. É apenas uma ferramenta que auxilia na tarefa de gerenciamento e versão. Erros humanos podem, e acontecem, acontecer a qualquer momento fazendo com que o Git passe de “mocinho” para “vilão”.

O Git é um software livre distribuído sobre os termos da GNU.

Sabores de Git

GitHub

É considerado o sabor de Git mais utilizado no mundo, com mais de 3 milhões de usuários ativos contribuindo com códigos open source para projetos pessoais e comerciais, para divulgação de trabalhos ou de forma colaborativa com o intuito de identificar e corrigir falhas e bugs.

Devido a credibilidade e confiança que o GitHub proporciona, WordPress, Linux e Atom, são exemplos de projetos OpenSource, muito conhecidos e que utilizam o GitHub para seu crescimento.

O usuário tem 2 opções de conta na hora de se cadastrar. Caso escolha a conta gratuita, todos os repositórios que criar sempre serão públicos. Caso escolha conta paga, o usuário tem a opção de deixar seu repositório público ou privado, dessa forma ninguém teria acesso ao seu projeto. Seu repositório seria utilizado apenas como armazenamento, controle de versão sem colaboração da comunidade.

GitLab

Uma empresa com 6 funcionários, administram mais de 600 colaboradores OpenSource. É muito similar ao GitHub, sua maior diferença é que o usuário pode escolher por armazenar os códigos em servidores do próprio usuário, e não em servidores operados pelo próprio Git.

Dentre as mais de 100 mil organizações que utilizam o GitLab, estão a NASA e a Alibaba.

Google Code [deprecated]

Site da própria companhia google, criado para que desenvolvedores utilizem códigos-fonte abertos e uma lista de serviços que suportam APIs públicas do google.

O Git Flow

O Git Flow é uma maneira dinâmica e ativa de organização de branches dentro do Git. Com base nessa metodologia, o Git Flow criou um ferramental para auxiliar esta administração. Ele agrupa um conjunto de comandos dentro de um único comando o intuito de auxiliar no gerenciamento e na manutenção do repositório.

Além de todo o conceito prático que será mostrado, a essência do Git Flow é sua administração e seus processos. Para que haja um bom resultado com esta metodologia, é necessário que todos os passos do seu processo seja seguido rigorosamente. O não cumprimento desse quesito pode resultar em grandes problemas no decorrer da evolução do projeto.No site oficial do Git Flow há maiores informações.

Os ramos (branches)

Master

A branch Master é a cópia fiel do sistema em produção, um espelho de todo o sistema que está operando em produção. Em tese, se algo acontece com o sistema de produção, a master deve estar preparada para subir para produção e continuar operando normalmente como antes. Só deve existir uma branch Master no projeto, apenas um Fluxo (Flow) de evolução.

Develop

A branch Develop é a base de trabalho e desenvolvimento do projeto. A Develop sempre está sincronizada com a Master, sempre. Todas as novas funcionalidades (Features) e toda a evolução do projeto é feita com base na branch Develop. Assim como a Master, só deve existir apenas uma branch Develop, apenas um Fluxo (Flow) de evolução.

Features

A branch Features é o conjunto de branches que compõe toda a evolução do projeto. Com base na Develop, toda nova funcionalidade a ser implementada no sistema é feita pelo Fluxo (Flow) Features. Neste caso, podem existir N branches para este Fluxo (Flow). Em um mesmo Fluxo Features várias branches de novas funcionalidades podem coexistir simultaneamente. Todas serão “mergeadas” uma a uma para a Develop.

Release

E a branch que controla a versão do sistema. Quando há uma quantidade X de merges das Features com a Develop, um novo Release pode ser criado, criando uma nova versão para o sistema. Cada arquiteto ou responsável pelo projeto decide quando criar uma nova Release com base no que já foi produzido. Geralmente é nesta branch que acontecem todos os tipos de testes. Quando um Release é aprovado, ele é “mergeado” com a Master e com a Develop, para manter a base de desenvolvimento atualizada. Só deve existir apenas uma branch Release, apenas um Fluxo de evolução (Flow).

Hotfixes

Esta branch é utilizada para gerar correções que ocorrem em produção. Geralmente um erro no sistema de produção não pode esperar todo o fluxo de Develop, Feature, Release pra depois voltar para a Master. Erros no sistema de produção requerem imediatismo e é pra isso que a Hotfies existe. Quando um erro é encontrado em produção, uma Hotfix é criada com base na Master, corrigida e “mergeada” de volta para a Master e juntamente para a Develop. É muito importante a Develop receber esta atualização, pois se isto não for feito, o problema outrora corrigido pode voltar depois de uma nova Release. Não é aconselhável existirem várias branches de Hotfixes, mas muitas equipes optam por terem quando o sistema tem uma incidência muito grande de erros acontecendo em produção.

Iniciando o Git Flow

O Git Flow segue uma sequência de fluxos de branches e com base nesse fluxo todo o ciclo de vida do projeto é mantido atualizado e versionado.

Como descritos no tema anterior, cada branch (fluxo) tem seu papel e seguem todos em paralelos, como mostra a ilustração a seguir:

gitflow.png

Fonte: https://fpy.cz/pub/slides/git-workshop/images/gitflow.png

O exemplo, do ciclo de vida do Git Flow, a seguir, será demonstrado com base em um caminho feliz, situação a qual não ocorre nenhum erro durante o desenvolvimento do processo. Todo o passo-a-passo é executado com sucesso, não há exceções a serem tratadas neste exemplo.

Passo 1 – Clonando o repositório

Comando: git clone https://github.com/danilotecoliveira/GitFlowProject.git

Este artigo não abordará a criação de um projeto no Git. Partirá do princípio de que ele já esteja criado e iniciará aqui o processo de clone do repositório.

O processo de clonar o repositório é o mesmo do Git nativo como mostrado a seguir:

Passo 2 – Iniciando o Git Flow no projeto

Comando: git flow init

No momento da instalação o Git Flow mostrará os passos de configuração das branches de base. Um padrão já vem configurado e é aconselhável deixar a configuração padrão. Em cada branch é necessário especificar a configuração, mas neste caso será mantido o padrão utilizando a tecla ENTER em cada passo até a finalização do processo.

Após a finalização do processo é possível ver que um simples comando já configura o ambiente e ainda cria a branch de desenvolvimento develop.

Como citado anteriormente, o Git Flow customiza várias linhas de comando em apenas algumas, facilitando e otimizando o trabalho do desenvolvedor.

Passo 3 – Enviando para o Git as branches criadas

Comando: git push origin master && git push origin develop

Depois de criado as branches, é necessário enviá-las para o repositório remoto. Depois disto, a evolução do projeto poderá ser iniciada.

A imagem a seguir mostra que o repositório remoto foi atualizado com a branch Develop:

Passo 4 – Iniciando uma nova Feature

Comando: git flow feature start [nome_da_feature]

Este comando é mais um exemplo de várias ações dentro de um único comando. Após executar o comando de criação de Feature, o Git Flow cria a branch no Fluxo Feature e em seguida faz o checkout para a Feature criada.

Passo 5 – Criar um novo arquivo e enviá-lo para o repositório remoto

Comando: git push origin feature/[nome_da_feature]

Após a criação da nova Feature, os arquivos já podem ser criados e a evolução ocorre normalmente, os commits locais podem ser feitos e, ao terminar, é necessário enviar toda a implementação feita para o repositório remoto juntamente com a branch Feature criada no repositório local.

A imagem a seguir mostra que a branch Feature foi criada no repositório remoto.

Passo 6 – Finalizando a Feature criada

Comando: git flow feature finish [nome_da_feature]

Apenas um único comando é necessário para fazer o merge da Feature com a Develop, excluir a Feature criada e fazer o checkout para a branch Develop.

Passo 7 – Criando um Release

Comando: git flow release start [versao_da_release]

Após um conjunto de Features ter sido criado e “mergeados” com a Develop, um novo Release pode ser criado. Não há uma regra para quando um Release é criado, esta decisão cabe da equipe e dos responsáveis pelo projeto.

Ao executar o comando de criação de Release, o Git Flow cria a Release e faz o checkout para a nova branch criada.

Passo 8 – Publicando a Release

Comando: git flow release publish [versao_da_release]

Depois de todas as validações e testes necessários no Release criado, é possível publicar sua versão.

O comando de publicar um Release envia todo o conteúdo para o repositório remoto.

Em seguida, é necessário colocar uma mensagem para a publicação da Release.

Depois da mensagem, a tela de configuração de Tag é exibida.

Depois de tudo configurado, o Git Flow faz o merge para as branches Master e Develop, deleta a Release criada e faz o checkout para a Develop já atualizada.

Passo 9 – Publicando a Master e a Develop

Comando: git push origin develop && git push origin master

Agora, com o Release publicado e “mergeado” com a Master e a Develop, é necessário enviar para o repositório remoto as alterações feitas na Master e na Develop.

Passo 10 – Criando um Hotfix

Comando: git flow hotfix start [nome_da_hotfix]

É comum surgirem bugs no sistema de produção e muitos deles não podem esperar o processo de Feature, Release, teste e publicação. Pra isso o Fluxo de Hotfix foi criado. Ele é um Fluxo que segue a parte e depende somente da Master.

O comando mostrado cria um novo hotfix e faz o checkout para o mesmo criado.

Passo 12 – Finalizando a Hotfix

Comando: git flow hotfix publish [nome_do_hotfix] && git push origin hotfix [nome_do_hotfix]

Logo que o bug for corrigido e testado, o Hotfix pode ser publicado no repositóiro remoto.

Depois que configurados a publicação, o merge e a tag, o Git Flow faz o merge do Hotfix com a Master e a Develop.

Problemas do Git Flow

O Git Flow é tido como um dos principais modelos de organização de branches existentes no mercado de desenvolvimento. Tanto que o próprio Git possui uma extensão para facilitar a integração do seu repositório com a metodologia. Mas no universo de desenvolvimento de software, nenhum framework, linguagem ou ferramenta alcança a perfeição, ou pelo menos 100% de aceitação entre toda a comunidade. Existem certas situações que não são previstas por certa ferramenta, algumas cujos problemas ficam ainda piores quando certo método é utilizado, e pessoas que simplesmente não gostam do que é oferecido no modelo. Por isso, é importante elencar quais tipos de dificuldade a comunidade observou ao utilizar o modelo Git, para conseguir enxergar tendências de problemas ao se utilizar o modelo no futuro, e tentar contorná-los.

Independência de features

O principal desafio ao se trabalhar com Git Flow, é que o modelo assume que cada Branch, ou seja, cada implementação ou funcionalidade do sistema, é completamente independente de outras branches sendo desenvolvidas em paralelo. Mas na realidade, sabemos que uma branch pode sim conter alterações que impactam diretamente no desenvolvimento de outras. Além disso, o Git Flow recomenda que todas as features sejam desenvolvidas localmente, ou seja, uma branch não possui visão do que está acontecendo em outra, aliando isso ao possível impacto que os desenvolvimentos naturalmente têm entre si, problemas na hora do merge são muito difíceis de evitar. Dependendo do tamanho da branch e de suas ramificações no projeto, integrá-la com sucesso pode se tornar um árduo trabalho.

Difícil de se utilizar com métodos ágeis

Muitas empresas estão migrando para utilizar metodologias ágeis em seu ciclo de desenvolvimento. Alguns dos principais lemas nos quais as metodologias ágeis foram criadas incluem entregas rápidas para o cliente, e manutenção de qualidade. O problema é que, quando criamos branches para funcionalidades, nem sempre elas estarão completas para ser possível colocar no pacote de Release (um time ágil tem que entregar um release em um tempo variável de 1-4 semanas, segundo diretrizes).

Nesse caso, é comum que Releases sejam atropeladas para conseguir manter as entregas das branches solicitadas de maneira compatível. Além disso, caso essa branch seja integrada em uma Release futura, novos problemas de compatibilidade e merge surgirão, visto que novas atividades, não antes previstas quando o desenvolvimento se iniciou antes do atraso, estarão sendo desenvolvidas em paralelo.

Pode ser desnecessariamente complexo

O principal ponto a ser discutido como problema do Git Flow   é a dificuldade em ver a história e o progresso de desenvolvimento do sistema. Com tantas branches e releases acontecendo de maneira separada e simultânea em 2 fluxos (Develop e Master), pode ser difícil acompanhar o progresso de desenvolvimento simplesmente olhando o fluxo de commits do repositório. Além disso, por conta das constantes criações de branches diferentes, muitos problemas que acontecem no modelo se tornam corriqueiros e até mesmo naturais para o desenvolvedor resolver.
Tudo isso apenas aumenta a incidência de problemas e erros de merge que acontecem no dia a dia utilizando Git Flow.

Conclusão

Como vimos, o Git é uma ferramenta versátil, leve, colaborativa e completa, que se usada com planejamento, é uma grande aliada em seus projeto pessoais e comerciais. Praticamente todo tipo de projeto pode ser beneficiado com o uso do Git, ficando ao seu cargo adaptações conforme tamanho e complexidade do projeto.

O Git em termos práticos não tem segredo, seus comandos são simples e seguem uma ordem como vimos no Git Flow acima, tanto que se tentar fazer um “commit” sem dar um “add” antes, não vai conseguir, ou melhor, não terá arquivo para ser “comitado”.

O mais difícil nele, se é que podemos dizer isso, é você criar a sua experiência, seu modo de trabalhar com Git, seus costumes, sua organização.

Porém nem tudo pode ser tão belo quanto parece. Se você e/ou seu time não forem organizados, não se preocuparem em criar branches corretas, finalizar essas branches, ter calma e certeza ao realizar commits e pushes, você pode ter grandes dores de cabeça, já que se não percebido a tempo, podem ser feitas implementações em branchs com erros, ou pior, podem até ter erros em arquivos já finalizados.

De modo geral o Git e seus sabores, são excelentes ferramentas de versionamento. Crie sua conta em um dos sabores do Git, crie seu próprio repositório e pratique, pratique bastante, crie e recrie repositórios quantas vezes for preciso, o importante é estar familiarizado com a ferramenta e seguro com o seu uso, para que você possa colaborar com projetos públicos e também ser ajudado em seus próprios projetos.

Referências