Heading

Gitflow Workflow é um fluxo de trabalho Gitflow que ajuda no desenvolvimento contínuo de software e na implementação de práticas DevOps. Foi publicado pela primeira vez e tornado popular por Vincent Driessen na nvie. O Gitflow Workflow define um modelo de ramificação rigoroso, concebido em torno do lançamento do projecto. Isto fornece uma estrutura robusta para a gestão de projectos de maior envergadura.

Gitflow é ideal para projectos que tenham um ciclo de lançamento programado e para a melhor prática DevOps de entrega contínua. Este fluxo de trabalho não acrescenta quaisquer novos conceitos ou comandos para além do que é necessário para o Fluxo de Trabalho do Ramo de Funcionalidades. Em vez disso, atribui papéis muito específicos a diferentes ramos e define como e quando estes devem interagir. Para além de feature ramos, utiliza ramos individuais para preparar, manter, e gravar lançamentos. É claro que também se pode tirar partido de todos os benefícios do Fluxo de Trabalho dos Ramos de Características: pedidos de puxar, experiências isoladas, e colaboração mais eficiente.

Começar

Fluxo de Git é realmente apenas uma ideia abstracta de um fluxo de trabalho Git. Isto significa que dita que tipo de ramos devem ser criados e como fundi-los juntos. Iremos abordar os objectivos dos ramos abaixo. O conjunto de ferramentas de git-flow é uma ferramenta de linha de comando real que tem um processo de instalação. O processo de instalação para o git-flow é simples. Os pacotes para git-flow estão disponíveis em múltiplos sistemas operativos. Em sistemas OSX, pode executar brew install git-flow. No Windows terá de descarregar e instalar o git-flow. Após instalar o git-flow, pode utilizá-lo no seu projecto executando git flow init. O git-flow é um invólucro em torno de Git. O comando git flow init é uma extensão do comando padrão git init e não altera nada no seu repositório a não ser a criação de filiais para si.

Como funciona

Desenvolver e Ramos Mestres

Em vez de um único master ramo, este fluxo de trabalho utiliza dois ramos para registar o histórico do projecto. O master ramo armazena o histórico oficial do lançamento, e o develop ramo serve como um ramo de integração de características. É também conveniente marcar todos os commits no master ramo com um número de versão.

O primeiro passo é complementar o padrão master com um develop ramo. Uma forma simples de o fazer é um programador criar uma sucursal vazia develop localmente e empurrá-la para o servidor:

git branch develop
git push -u origin develop

Esta sucursal conterá o histórico completo do projecto, enquanto master conterá uma versão abreviada. Outros programadores deverão agora clonar o repositório central e criar um ramo de localização para develop.

Ao utilizar a biblioteca de extensão git-flow, a execução de git flow init num repo existente criará o ramo develop:

$ git flow init
Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: 
Branch name for "next release" development: 
How to name your supporting branch prefixes?
Feature branches? 
Release branches? 
Hotfix branches? 
Support branches? 
Version tag prefix? 
$ git branch
* develop
master

Ramo de Funcionalidade

Cada nova funcionalidade deve residir no seu próprio ramo, que pode ser empurrado para o repositório central para backup/colaboração. Mas, em vez de ramificação de masterfeature os ramos utilizam develop como ramo principal. Quando uma característica está completa, é fundida de novo em desenvolvimento. As características nunca devem interagir directamente com master.

Nota que feature ramos combinados com o develop ramo é, para todos os efeitos, o Fluxo de Trabalho do Ramo de Característica. Mas, o Fluxo de Trabalho de Gitflow não pára aí.

Feature ramos são geralmente criados até ao último develop ramo.

Criando um ramo de característica

Sem as extensões de git-flow:

git checkout develop
git checkout -b feature_branch

Ao utilizar a extensão de git-flow:

git flow feature start feature_branch

Continuar o seu trabalho e utilizar Git como normalmente faria.

Terminar um ramo de funcionalidade

Quando terminar o trabalho de desenvolvimento da funcionalidade, o passo seguinte é fundir o feature_branch em develop.

Sem as extensões de git-flow:

git checkout develop
git merge feature_branch

Utilizando as extensões de git-flow:

git flow feature finish feature_branch

Ramais de Lançamento

Once develop adquiriu características suficientes para um lançamento (ou uma data de lançamento pré-determinada está a aproximar-se), bifurca-se um release ramo de develop. A criação deste ramo inicia o próximo ciclo de lançamento, pelo que não podem ser adicionadas novas funcionalidades após este ponto apenas correcções de bugs, geração de documentação, e outras tarefas orientadas para o lançamento devem ir para este ramo. Uma vez pronto para ser enviado, o ramo release é fundido em master e etiquetado com um número de versão. Além disso, deve ser fundido novamente em develop, que pode ter progredido desde que o lançamento foi iniciado.

Utilizar um ramo dedicado para preparar lançamentos torna possível a uma equipa polir o actual lançamento enquanto outra equipa continua a trabalhar nas funcionalidades para o próximo lançamento. Também cria fases de desenvolvimento bem definidas (por exemplo, é fácil dizer, “Esta semana estamos a preparar a versão 4.0,” e vê-la realmente na estrutura do repositório).

Fazer release ramos é outra operação de ramificação simples. Como feature ramos, release ramos são baseados no develop ramo. Um novo release ramo pode ser criado utilizando os seguintes métodos.

Sem as extensões de git-flow:

git checkout develop
git checkout -b release/0.1.0

Ao utilizar as extensões de git-flow:

Após o lançamento estar pronto para ser enviado, será fundido em master e develop, então o release ramo será apagado. É importante fundir novamente em develop, porque as actualizações críticas podem ter sido adicionadas ao ramo release e precisam de estar acessíveis a novas funcionalidades. Se a sua organização enfatiza a revisão do código, este seria o local ideal para um pedido de puxar.

Para terminar um release branch, use os seguintes métodos:

Sem as extensões de git-flow:

Or com a extensão de git-flow:

git flow release finish '0.1.0'

git checkout master
git checkout -b hotfix_branch

$ git flow hotfix start hotfix_branch

git checkout master
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch

$ git flow hotfix finish hotfix_branch

git checkout master
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout master
git merge develop
git branch -d feature_branch

git checkout master
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout master
git merge hotfix_branch