As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Estratégia de ramificação do Gitflow
O Gitflow é um modelo de ramificação que envolve o uso de várias ramificações para mover o código do desenvolvimento para a produção. O Gitflow funciona bem para equipes que têm ciclos de lançamento programados e precisam definir uma coleção de recursos como um lançamento. O desenvolvimento é concluído em ramificações de recursos individuais que são mescladas, com aprovação, em uma ramificação de desenvolvimento, que é usada para integração. Os recursos desse ramo são considerados prontos para produção. Quando todos os recursos planejados tiverem sido acumulados na ramificação de desenvolvimento, uma ramificação de lançamento será criada para implantações em ambientes superiores. Essa separação melhora o controle sobre quais alterações estão sendo transferidas para qual ambiente nomeado em um cronograma definido. Se necessário, você pode acelerar esse processo para um modelo de implantação mais rápido.
Para obter mais informações sobre a estratégia de ramificação do Gitflow, consulte os seguintes recursos:
+ [Implemente uma estratégia de ramificação do Gitflow para DevOps ambientes com várias contas](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) (orientação prescritiva)AWS
+ [O blog original do Gitflow](https://nvie.com/posts/a-successful-git-branching-model/) (publicação do blog do Vincent Driessen)
+ [Gitflow workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) (Atlassian)
**Topics**
+ [
# Visão geral visual da estratégia do Gitflow
](visual-overview-of-the-gitflow-strategy.md)
+ [
# Filiais em uma estratégia Gitflow
](branches-in-a-gitflow-strategy.md)
+ [
# Vantagens e desvantagens da estratégia Gitflow
](advantages-and-disadvantages-of-the-gitflow-strategy.md)
# Visão geral visual da estratégia do Gitflow
O diagrama a seguir pode ser usado como um [quadrado de Punnett](https://en.wikipedia.org/wiki/Punnett_square) para entender a estratégia de ramificação do Gitflow. Alinhe as ramificações no eixo vertical com os AWS ambientes no eixo horizontal para determinar quais ações realizar em cada cenário. Os números circulados guiam você pela sequência de ações representada no diagrama. Para obter mais informações sobre as atividades que ocorrem em cada ambiente, consulte [DevOps ambientes](understanding-the-devops-environments.md) neste guia.
![\[Quadrado de Punnett das atividades do Gitflow em cada filial e ambiente\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-diagram.png)
# Filiais em uma estratégia Gitflow
Uma estratégia de ramificação do Gitflow geralmente tem as seguintes ramificações.
![\[As filiais e ambientes em uma estratégia de ramificação do Gitflow.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-branching-strategy.png)
## ramificação de recursos
`Feature`filiais são filiais de curto prazo nas quais você desenvolve recursos. A `feature` ramificação é criada pela ramificação da `develop` ramificação. Os desenvolvedores iteram, confirmam e testam o código na `feature` ramificação. Quando o recurso é concluído, o desenvolvedor promove o recurso. Há apenas dois caminhos a partir de uma ramificação de recursos:
+ Mesclar com a filial `sandbox`
+ Crie uma solicitação de mesclagem na filial `develop`
| | |
| --- |--- |
| Convenção de nomenclatura: | `feature/__` |
| Exemplo de convenção de nomenclatura: | `feature/123456_MS_Implement_Feature_A` |
## filial de sandbox
A `sandbox` filial é uma ramificação não padrão de curto prazo do Gitflow. No entanto, é útil para o desenvolvimento de CI/CD tubulações. A `sandbox` filial é usada principalmente para os seguintes propósitos:
+ Execute uma implantação completa no ambiente sandbox usando os CI/CD pipelines em vez de uma implantação manual.
+ Desenvolva e teste um pipeline antes de enviar solicitações de mesclagem para testes completos em um ambiente inferior, como desenvolvimento ou teste.
`Sandbox`os galhos são de natureza temporária e não devem ter vida longa. Eles devem ser excluídos após a conclusão do teste específico.
| | |
| --- |--- |
| Convenção de nomenclatura: | `sandbox/__` |
| Exemplo de convenção de nomenclatura: | `sandbox/123456_MS_Test_Pipeline_Deploy` |
## desenvolver filial
A `develop` filial é uma filial de longa duração em que os recursos são integrados, criados, validados e implantados no ambiente de desenvolvimento. Todas as `feature` filiais são mescladas na `develop` ramificação. As fusões na `develop` ramificação são concluídas por meio de uma solicitação de mesclagem que requer uma compilação bem-sucedida e duas aprovações do desenvolvedor. Para evitar a exclusão, ative a proteção da ramificação na `develop` ramificação.
| | |
| --- |--- |
| Convenção de nomenclatura: | `develop` |
## ramificação de lançamento
No Gitflow, `release` filiais são filiais de curto prazo. Essas ramificações são especiais porque você pode implantá-las em vários ambientes, adotando a metodologia de criar uma vez e implantar muitos. `Release`as filiais podem ter como alvo os ambientes de teste, preparação ou produção. Depois que uma equipe de desenvolvimento decidiu promover recursos em ambientes superiores, eles criam uma nova `release` ramificação e usam incrementar o número da versão da versão anterior. Nos portões de cada ambiente, as implantações exigem aprovações manuais para prosseguir. `Release`as filiais devem exigir que uma solicitação de mesclagem seja alterada.
Depois que a `release` ramificação for implantada na produção, ela deverá ser mesclada novamente às `main` ramificações `develop` e para garantir que quaisquer correções de bugs ou hotfixes sejam incorporados novamente aos esforços futuros de desenvolvimento.
| | |
| --- |--- |
| Convenção de nomenclatura: | `release/v{major}.{minor}` |
| Exemplo de convenção de nomenclatura: | `release/v1.0` |
## ramificação principal
A `main` ramificação é uma ramificação de longa duração que sempre representa o código que está sendo executado na produção. O código é mesclado automaticamente na `main` ramificação de uma ramificação de lançamento após uma implantação bem-sucedida do pipeline de lançamento. Para evitar a exclusão, ative a proteção da ramificação na `main` ramificação.
| | |
| --- |--- |
| Convenção de nomenclatura: | `main` |
## ramificação de correção de bugs
A `bugfix` ramificação é uma ramificação de curto prazo usada para corrigir problemas em ramificações de lançamento que não foram lançadas para produção. Uma `bugfix` ramificação só deve ser usada para promover correções em `release` ramificações para os ambientes de teste, preparação ou produção. Um `bugfix` galho é sempre ramificado de um `release` galho.
Depois que a correção de bug for testada, ela poderá ser promovida para a `release` ramificação por meio de uma solicitação de mesclagem. Em seguida, você pode empurrar a `release` ramificação para frente seguindo o processo de liberação padrão.
| | |
| --- |--- |
| Convenção de nomenclatura: | `bugfix/__` |
| Exemplo de convenção de nomenclatura: | `bugfix/123456_MS_Fix_Problem_A` |
## ramificação de hotfix
A `hotfix` filial é uma filial de curto prazo usada para corrigir problemas na produção. Ele só pode ser usado para promover correções que devem ser aceleradas para chegar ao ambiente de produção. Um `hotfix` galho é sempre ramificado. `main`
Depois que o hotfix for testado, você poderá promovê-lo para produção por meio de uma solicitação de mesclagem na `release` ramificação a partir da qual foi criada. `main` Para testar, você pode então empurrar a `release` ramificação para frente seguindo o processo de liberação padrão.
| | |
| --- |--- |
| Convenção de nomenclatura: | `hotfix/__` |
| Exemplo de convenção de nomenclatura: | `hotfix/123456_MS_Fix_Problem_A` |
# Vantagens e desvantagens da estratégia Gitflow
A estratégia de ramificação do Gitflow é adequada para equipes maiores e mais distribuídas que têm requisitos rígidos de liberação e conformidade. O Gitflow contribui para um ciclo de lançamento previsível para a organização, e isso geralmente é preferido por organizações maiores. O Gitflow também é adequado para equipes que precisam de barreiras para concluir adequadamente o ciclo de vida de desenvolvimento de software. Isso ocorre porque há várias oportunidades de análises e garantia de qualidade incorporadas à estratégia. O Gitflow também é adequado para equipes que precisam manter várias versões dos lançamentos de produção simultaneamente. Algumas desvantagens do GItflow são que ele é mais complexo do que outros modelos de ramificação e requer adesão estrita ao padrão para ser concluído com sucesso. O Gitflow não funciona bem para organizações que buscam a entrega contínua devido à natureza rígida do gerenciamento de ramificações de lançamento. As ramificações de lançamento do Gitflow podem ser ramificações de longa duração que podem acumular dívidas técnicas se não forem tratadas adequadamente em tempo hábil.
## Vantagens
O desenvolvimento baseado em Gitflow oferece várias vantagens que podem melhorar o processo de desenvolvimento, agilizar a colaboração e aprimorar a qualidade geral do software. A seguir estão alguns dos principais benefícios:
+ **Processo de lançamento previsível** — O Gitflow segue um processo de lançamento regular e previsível. É adequado para equipes com cadências regulares de desenvolvimento e lançamento.
+ **Colaboração aprimorada** — O Gitflow incentiva o uso de `feature` e ramificações. `release` Essas duas ramificações ajudam as equipes a trabalhar em paralelo com dependências mínimas umas das outras.
+ **Adequado para vários ambientes** — o Gitflow usa `release` ramificações, que podem ser ramificações de vida mais longa. Essas filiais permitem que as equipes direcionem lançamentos individuais por um longo período de tempo.
+ **Várias versões em produção** — Se sua equipe oferece suporte a várias versões do software em produção, as `release` filiais do Gitflow atendem a esse requisito.
+ **Análises de qualidade de código integradas** — O Gitflow exige e incentiva o uso de análises e aprovações de código antes que o código seja promovido para outro ambiente. Esse processo elimina o atrito entre os desenvolvedores ao exigir essa etapa para todas as promoções de código.
+ **Benefícios da organização** — O Gitflow também tem vantagens em nível organizacional. O Gitflow incentiva o uso de um ciclo de lançamento padrão, o que ajuda a organização a entender e antecipar o cronograma de lançamentos. Como a empresa agora entende quando novos recursos podem ser fornecidos, há menos atrito com os cronogramas porque há datas de entrega definidas.
## Desvantagens
O desenvolvimento baseado em Gitflow tem algumas desvantagens que podem afetar o processo de desenvolvimento e a dinâmica da equipe. A seguir estão algumas desvantagens notáveis:
+ **Complexidade** — O Gitflow é um padrão complexo para novas equipes aprenderem, e você deve seguir as regras do Gitflow para usá-lo com sucesso.
+ **Implantação contínua** — O Gitflow não se encaixa em um modelo em que muitas implantações são lançadas para produção de forma rápida. Isso ocorre porque o Gitflow requer o uso de várias ramificações e um fluxo de trabalho rígido que rege a `release` ramificação.
+ **Gerenciamento de filiais** — O Gitflow usa muitas filiais, o que pode ser difícil de manter. Pode ser difícil rastrear as várias ramificações e mesclar o código lançado para manter as ramificações devidamente alinhadas umas com as outras.
+ **Débito técnico** — Como os lançamentos do Gitflow geralmente são mais lentos do que os outros modelos ramificados, mais recursos podem se acumular para o lançamento, o que pode causar o acúmulo de dívidas técnicas.
As equipes devem considerar cuidadosamente essas desvantagens ao decidir se o desenvolvimento baseado em Gitflow é a abordagem correta para o projeto.