O Gitflow foi idealizado por Vincent Driessen em 2010 e trata-se de um padrão de gerenciamento de fluxo de trabalho que tem como base o Git. Seu modelo de ramificações possui uma estrutura bem definida, com funções próprias e regras de interação. Na prática, esse rigor garante organização e controle para o gerenciamento de grandes projetos.
Figura 1.1 - Linha do tempo em um projeto com o padrão Gitflow
Ramificações
Para gerenciar o fluxo de trabalho com o Gitflow não é necessário novas tecnologias, conceitos ou comandos, apenas os recursos já disponíveis no Git, como branch (ramo), merge, checkout, tags etc.
O Gitflow possui 5 tipos de ramos, dois deles são considerados principais (master e develop) e os demais secundários ou temporários (release, feature e hotfix/bugfix). Veremos a seguir a definição de cada um deles.
Principais
O ramo master é responsável por manter o histórico de todas as versões de lançamento (produção) do projeto, enquanto o developer, que é derivado do master assim que o repositório é criado, possui o histórico completo do produto. Eles seguiram em paralelo, de forma contínua e nunca serão mesclados diretamente durante toda a vida do projeto, assim, o develop sempre utilizará um ramo secundário (release) para atualizar o master.
O ramo develop reflete o estado mais atual das funcionalidades que estão prontas (desenvolvidas) e foram elegíveis para ir para a próxima release, já o master possui o conteúdo um pouco mais defasado, porém mais seguro para o usuário do sistema.
Figura 1.2 - Destaque para os ramos principais: master e develop
Novos recursos
Para cada nova funcionalidade a ser criada no sistema será gerado um ramo feature próprio a partir da última versão do develop, o ramo mais estável em desenvolvimento. O tempo de vida do novo ramo poderá variar de acordo com o tamanho da nova funcionalidade, porém, após finalizado será mesclado com o develop e excluído em seguida.
Caso seu projeto possua um gerenciador de tarefas, como Jira ou Redmine, é uma boa prática criar os ramos do tipo feature com o nome dos tickets, ex.: feature/<número do ticket>, facilitando a identificação e objetivo do ramo.
Figura 1.3 - Os branches feature só interagem com o develop
Lançamentos
Assim que o ramo develop estiver pronto para um lançamento, seja por acúmulo de novos recursos ou data pré-definida, um ramo release deve ser gerado a partir do develop, dando início a um novo ciclo de lançamento. Por serem consideradas versões "fixas", os ramos de lançamento são isolados em um ambiente de testes e novos recursos não devem ser adicionados a eles, apenas correções de bug, geração de documentação e outras tarefas relacionadas ao lançamento.
Na etapa final de lançamento, o ramo release será mesclado tanto com o master, dando origem a uma nova versão de produção, quanto com o develop, já que correções de bugs e pequenos ajustes foram realizados durante o release. Ao final dos dois merges, o ramo release é excluído.
Figura 1.4 - Fluxo do lançamento de versão
Normalmente os nomes dados aos ramos do tipo release seguem um padrão release/<versão>, com versões incrementais, ex.: 1.0 (major version), 1.0.1 (minor version). O Gitflow também adota a prática de utilizar tags para marcar os releases após irem ao master, então, após fazer o merge de um release para o master, uma Tag com o número da versão pode ser criada para marcar o ponto (commit) do deploy.
Manutenções
Os ramos de manutenção (bugfix e hotfix) são utilizados para corrigir bugs ou problemas críticos que não podem esperar o próximo ciclo de lançamento.
Figura 1.5 - Fluxo do hotfix
- bugfix: se um bug é encontrando durante a etapa de testes no release, é criado um branch bugfix, a correção é feita, ocorre um merge com o ramo release e o ramo de correção é excluído em seguida.
- hotfix: criado ao encontrar um problema crítico que necessita de uma ação imediata no master. Assim, após gerar um ramo hotfix a partir do master e corrigir o problema, serão realizados merges no master, com criação de uma nova tag, e no developer. Ao final, o ramo hotfix é excluído.
A nomenclatura usada para o hotfix e bugfix seguem o seguinte padrão: hotfix/<versão> e bugfix/<versão>, onde <versão> é o valor da nova tag aplicado em master ou release após mesclar o ramo.
Nesta página
| Índice |
|---|
Trabalhando com o Cronapp IDE e utilizando repositórios GIT para o controle de versão é possível integrar sua equipe, controlar o desenvolvimento conjunto e restaurar versões anteriores do seu projeto, além de manter seu código organizado. Utilizamos a metodologia do Git Flow que organiza suas branches de modo a seguir um padrão bem definido. Essa organização tornará possível fornecer seu código com mais agilidade para equipe de teste e, sucessivamente, com maior segurança para seu usuário final.
Definição
O GitFlow trata-se de um modelo de organização de branches desenvolvido especialmente para o git permitindo seu uso de forma fácil com qualquer repositório. Ele estabelece algumas regras de nomenclatura para diferentes tipos de branches de acordo com suas funções. Os branches definidos pelo ele e suas respectivas descrições são os seguintes:
- Branch Master: É o branch em que o código está em nível de produção, ou seja, que está sendo usado diretamente pelos usuários. Eventualmente, todo código produzido em outros branches é adicionado ao branch master em algum momento do desenvolvimento;
- Branch Develop: Nesse branch o código está em um nível preparatório para deploy. O código do develop é fornecido pelos branches feature e hotfix, que ao serem adicionados, são testados, passam por mais um processo e somente depois as atualizações do branch develop são juntadas ao branch master;
Branch de Release: O branch release tem um nível de confiança maior que do que o Branch develop. Ele resume as funções que uma nova versão do seu projeto terá e será preparada para ser mergeada ao branch master e ao branch develop (para o caso de bugs terem sido corrigidos no release), criando uma tag com o número da nova versão. Geralmente, é nomeado de release/[numero-da-versao];
Branch de Hotfix: É criado a partir do branch master, quando acontece algum problema em produção. Seu merge é feito no master e no develop, para que sejam feitas as correções também no código que está sendo desenvolvido. Ele também cria uma tag para indicar as correções feitas em uma determinada versão, geralmente recebe o nome de hotfix/[numero-da-versao];
- Branch de Feature: No branch feature são commitados códigos necessários para criar uma nova funcionalidade. Ele sai do develop e fazem mergem também no develop (pois uma funcionalidade pode depender diretamente de outra funcionalidade) e geralmente recebem o nome de feature/[descricao-da-funcionalidade].
Figura 1 - Fluxo do Git Flow
Para realizar esse processo seria necessário utilizar uma grande quantidade de comandos para executar cada passo, por isso é necessário automatizar uma quantidade necessária de código para seguir o fluxo e tornar cada passo mais legível. O Git Flow é um conjunto de extensões para o GIT que permite abstrair esse fluxo e assim o tornando mais prático e intuitivo.
Comandos
Basicamente, os principais comandos permitidos pelo Git Flow são os seguintes:
Figura 2 - Principais comandos do Git Flow
Git Flow no Cronapp IDE
O Cronapp ainda não dá suporte aos comandos do Git Flow, porém dá suporte indireto com facilitadores para criação de branches e merge. É possível efetuar as ações dos comandos direto no GIT com o Cronapp IDE, como criar branches e realizar merges. Você poderá executar essas operações, clicando com o botão direito no seu projeto e selecionando a opção Equipe. Nessa opção, é possível fazer merges (1) e criar novos branches (2) em seu projeto (Figura 3).
Figura 3 - Caminho para fazer merges e criar novos branches
Leituras recomendadas
| title | Nesta página |
|---|
| Índice |
|---|