# 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:

![](https://3697290398-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M7iQOq9eJJ2zoW1Ls4P%2F-M7mLLMad4lGaMuGC9lg%2F-M7mLvhzzPwWtsqHQCMH%2Ffluxo-git-flow.png?alt=media\&token=9d5de518-c6f0-45b9-bfdc-5147c4b8d808)

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](https://3697290398-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M7iQOq9eJJ2zoW1Ls4P%2F-M7rzbybQyuuzqS3aWif%2F-M7mSFYhAx839DBqUSiW%2Fcartao-danilo.png?alt=media\&token=8454d694-e186-4db2-9072-d6404c23d5b4)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://developers-friends.gitbook.io/blog/git/git-flow-1.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.