---
sidebar_position: 3
title: "Git Flow"
---

Esta página descreve o fluxo de branches e processo de contribuição ao repositório.

## Branches principais

```mermaid
gitGraph
    commit id: "estado inicial"
    branch develop
    checkout develop
    commit id: "nova funcionalidade A"
    branch feature/exemplo
    checkout feature/exemplo
    commit id: "implementa mudança"
    commit id: "ajusta detalhe"
    checkout develop
    merge feature/exemplo id: "merge via PR"
    commit id: "prepara pacote"
    checkout main
    merge develop id: "release"
```

| Branch | Propósito |
|---|---|
| `main` | Código estável, reflete produção |
| `develop` | Integração contínua, ponto de partida para features |
| `feature/*` | Desenvolvimento de funcionalidade ou correção |
| `fix/*` | Correção de bug |
| `chore/*` | Tarefas de manutenção sem impacto funcional |

## Fluxo de desenvolvimento

```mermaid
flowchart TD
    A[Criar branch a partir de develop] --> B[Desenvolver e commitar localmente]
    B --> C[Push da branch]
    C --> D[Abrir Pull Request para develop]
    D --> E[Code review]
    E --> F[Merge em develop]
    F --> G[Validação em homologação]
    G --> H[PR de develop para main]
    H --> I[Merge em main - release]
```

### 1. Criar branch a partir de develop

```bash
git checkout develop
git pull
git checkout -b feature/nome-descritivo
```

Sempre parta de `develop` atualizado.

### 2. Commitar com padrão convencional

Use o padrão Conventional Commits:

```
feat: adiciona atividade de lógica sequencial
fix: corrige validação da fase 3 do aspirador
chore: atualiza dependência do Blockly
refactor: extrai lógica de storage para serviço dedicado
```

Referência externa: https://www.conventionalcommits.org/

### 3. Abrir PR para develop

- Título claro e no mesmo padrão do commit principal.
- Descreva o que muda e por quê.
- Inclua print ou gif se houver mudança visual.

### 4. Merge em develop e validação

Após aprovação, o merge vai para `develop`. A homologação é testada manualmente a partir desse estado.

### 5. Release para main

Quando `develop` está estável, abre-se PR de `develop` → `main`. O merge representa a release.

## Regras do repositório

- Não faça push direto em `main` ou `develop`.
- PRs precisam de ao menos uma aprovação antes do merge.
- Branches devem ser deletadas após o merge.
- Evite acumular muitas mudanças em uma única branch - PRs menores são mais fáceis de revisar.

Referência externa: https://nvie.com/posts/a-successful-git-branching-model/
