# Branches, Commit e Melhores Práticas

### Nomenclatura de branches

Use sempre letras minúsculas e hífens como separador. O prefixo descreve a intenção da mudança:

| Prefixo | Quando usar |
|---|---|
| `feat/` | Nova funcionalidade ou novo recurso (novo cluster, nova VM, novo serviço) |
| `upgrade/` | Atualização de versão de ferramenta, imagem ou dependência |
| `fix/` | Correção de configuração com defeito ou comportamento incorreto |
| `resize/` | Ajuste de recursos de hardware (CPU, memória, disco) |
| `docs/` | Alterações exclusivamente em documentação |

**Exemplos:**
```
feat/cluster-portal
upgrade/k3s-1.32
fix/rede-portal-ingress
resize/admin-node1-memoria
docs/workflow-infra
```

---

### Mensagens de commit

Use uma linha curta no imperativo descrevendo **o que** foi feito, com um prefixo de tipo e escopo opcional:

```
<tipo>(<escopo>): <descrição curta>
```

| Tipo | Uso |
|---|---|
| `feat` | Nova funcionalidade |
| `fix` | Correção de bug ou configuração errada |
| `upgrade` | Atualização de versão |
| `refactor` | Reorganização sem mudança de comportamento |
| `docs` | Documentação |
| `chore` | Manutenção (ajustes de CI, lock files) |

**Exemplos:**
```
feat(clusters): adiciona cluster portal com 3 nós k3s
fix(admin): corrige IP do gateway do nó admin-node1
upgrade(cert-manager): atualiza para v1.21.0
chore(ci): adiciona tag vsphere nos jobs de apply
```

---

### Regras gerais

- **Nunca** commite diretamente na `main`
- **Nunca** use `git push --force` na `main`
- **Nunca** aplique mudanças manualmente no ambiente sem antes registrar no repositório. TODAS as alterações de infraestrutura devem ser feitas via GitLab.
- Secrets e senhas **nunca** vão no código — use as variáveis de CI configuradas no grupo `dicom` do GitLab ou no projeto específico que precise de acesso à variável.