> For the complete documentation index, see [llms.txt](https://developers-friends.gitbook.io/blog/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers-friends.gitbook.io/blog/git/git-flow-1.md).

# Git Flow

## Teoria

É muito comum vermos desenvolvedores utilizando somente um *branch* para fazer commits em projetos pessoais. Isto não é errado, é muito tranquilo de se controlar tudo em um *branch* quando se está desenvolvendo sozinho, mas o cenário muda bastante quando temos que interagir com mais desenvolvedores, seja em um projeto de código aberto(opensource) ou privado.

Nessas horas é importante que se tenha total controle do que está sendo produzido por sua equipe, onde, ao mesmo tempo são corrigidas falhas, implementadas novas funcionalidades e o ideal é ter o seu código de produção com total funcionamento entregue ao cliente.

É aí que o [**Fluxo Git Flow**](https://nvie.com/posts/a-successful-git-branching-model/) nos ajuda, olhe a imagem abaixo para entender melhor:

![](/files/-M7mLvhzzPwWtsqHQCMH)

O **Git Flow** é um modelo de conjunto de instruções que você e/ou equipes de desenvolvimento podem seguir para organizar os *branches*.

É importante ressaltar que o Git Flow são **orientações** e **não regras**, ou seja, você não precisa seguir 100% ao pé da letra, acho bacana e até saudável que pensemos em adaptações de acordo com a equipe de desenvolvimento e o modelo de trabalho.

### Os *branches* principais

A **master** deve ser o principal *branch* onde o código-fonte sempre reflete um estado pronto que, quando versionado, será publicado em produção.

A **develop** sempre deve conter o código mais atual, ou seja, o que está sendo desenvolvido no momento. Isto é possível fazendo com que  os *branches* de features sejam criados através dela e no fim de seu ciclo, todo o código produzido seja mesclado *(merge)* na develop.\
\
Quando o código-fonte na *develop* atinge um ponto estável e está pronto para ser liberado, todas as alterações devem ser mescladas *(merge)* na **master** de alguma forma e marcadas com um número de release *(tag)*. 

{% hint style="info" %}
Iremos nos aprofundar mais detalhadamente sobre os conceitos de branches e tags nos próximos posts.
{% endhint %}

### Os *branches* de apoio

Junto aos principais *branches*, master e develop, há diversos *branches* ramificadas de apoio para auxiliar o desenvolvimento paralelo entre os membros da equipe, *facilitar o rastreamento* de recursos, *preparar releases* de produção e ajudar a *corrigir instantaneamente problemas de produção (hotfix)*.

**Ou seja:**

* **feature**: para novas implementações
* **release**: para finalizar releases e tags
* **hotfix**: para resolver problemas críticos em produção que não podem esperar um novo release

{% hint style="info" %}
Para saber mais sobre cada um dos *branches* de apoio e suas configurações, navegue pela seção sobre Git Flow. 
{% endhint %}

**Obrigado por chegar até aqui!** :grin:

![O Autor](/files/-M7mSFYhAx839DBqUSiW)