Afinal, o que são fluxos de trabalho Git (Git Workflow)?
O conjunto de definições que estipulam regras para criação, remoção, origem e destino de ramificações(branches) dentro do Git, definem um fluxo de trabalho(workflow).
Assim como Padrões de projeto (Design patterns), existem vários tipos de fluxo de trabalho para trabalhar com o Git. Cada fluxo é destinado a cenários que se encaixem na necessidade do time e do projeto.
O fluxo Feature Delivery Workflow (FDW) foi criado para atender cenários que exigem constante geração de pequenos blocos de artefatos que compõe blocos maiores de entregáveis, permitindo entregas sob demanda.
Sua premissa é permitir entregar somente o que já foi homologado pelo cliente, evitando a geração de grandes pacotes para homologação e facilitando integração com ferramentas de Continuous Delivery(CD).
O fluxo FDW possui alguns pontos em comum com o Gitflow Workflow. Entre suas principais diferenças, no fluxo FDW existe uma branch chamada homolog
voltada para a homologação de features que serão entregues, não existindo a necessidade da branch release
.
A representação do workflow FDW pode ser visualizada da seguinte maneira:
Merge Request, representado pela sigla MR, significa solicitação de mesclagem.Essa nomenclatura, também conhecida como Pull Request por usuários do Github, é utilizada para registrar a intenção de fusão de uma branch de origem para uma branch de destino. Nessa etapa são realizadas avaliações do código-fonte, chamadas de Code Review.
Características:
- É recomendável que o Merge request seja revisado por uma pessoa diferente da que o abriu.
- Para ter mais controle, permitir maior nivelamento e interação entre membros do time, as branches
develop
emaster
só devem aceitar novos commits através de um Code Review após a abertura do Merge Requests.
A branch develop
significa development e representa algo que está em desenvolvimento.
Suas características são:
- Branch mais atual do projeto
- Utilizada como referência para geração de branches
feature
ehomolog
- Só aceita novos commits através de um Merge Requests
- Representa o ambiente de produção contendo features mais recentes.
Funcionalidades são representadas por branches feature
. Elas apresentam as seguintes características:
- Novas features devem ser criadas à partir da branch
develop
- Sempre que for feito um novo Merge Request destinado à branch
develop
ouhomolog
, deve ser feito um merge da branchdevelop
para a branchfeature
- Sempre que o desenvolvimento de uma feature for concluído ela deve ser enviada para a branch
homolog
através de um merge - Assim que uma feature é validada dentro da branch
homolog
, deve ser feito um novo merge da branchdevelop
para a feature, garantindo que não existam conflitos ao unir afeature
com a branchdevelop
através do Merge Request.
Homolog é uma abreviação para homologation
. A branch homolog
está destinada a simular o ambiente de produção, simulando propositalmente eventuais erros que poderiam ser gerados durante a entrega de features.
Suas características são:
- A branch
homolog
NUNCA deve ser movida ou deve ser utilizada como referência para ser criadas novas branches - Merges através de Merge Request são opcionais variando de acordo com a necessidade do projeto
Merge para branch Homolog
No caso desse merge para branch homolog
siga os passos abaixo
- Acesse a branch
homolog
- Faça o merge para sua branch
git checkout origin/homolog
git merge feature/modulo/relatorio
- Resolver os conflitos
- Publicar o merge
git push origin homolog
Essa branch é criada como padrão pelo Git. É considerada a principal branch do projeto principalmente por representar a versão estável do repositório.
Suas características são:
- Representa o ambiente de produção da aplicação.
- Utilizada como referência para geração de branches
hotfix
- Tags e Releases são sempre gerados nesta branch.
Hotfix significam consertos rápidos e representa algo que precisa ser ajustado com urgência. Esses ajustes podem ser classificados como pequenas correções ou pequenas alterações.
Suas características são:
- Criada sempre à partir da branch
master
- Sempre que o desenvolvimento do hotfix é concluído, é necessário fazer um Merge na branch
homolog
. Caso o código seja validado com sucesso, devem ser criados dois Merge Requests, o primeiro para a branchmaster
e o segundo para a branchdevelop
As Tags representam o registro de um marco dentro do projeto. As releases tem como responsabilidade trazer quais foram os envolvidos.
No fluxo FWD os itens que compõe entregáveis estão descritos nos Merge Requests.
A geração de Releases é composta pela criação do Changelog contendo itens que foram realizados e criação de Tags versionando o código-fonte utilizando o Semantic versioning.
OBS: As Releases são geradas somente à partir da branch master
.
-
Se você perceber que algo esta errado, abra uma issue no GitHub.
-
Você mesmo pode consertar, simplesmente edite o arquivo no GitHub e abra um novo pull request. O repositório será atualizado assim que o seu pull request for aceito!
😃 ⚡