# Workflow e Comandos Git

Todo trabalho segue este fluxo, independentemente do repositório:

```
1. Atualizar repositório local (main)
2. Criar branch de trabalho
3. Fazer alterações e commits
4. Enviar branch para o GitLab (push)
5. Abrir Merge Request
6. Revisar output do CI
7. Solicitar aprovação
8. Revisor aprova e faz o merge
9. Revisor confere CI pós-merge e aciona o apply
```

### 1. Atualizar o repositório local antes de começar

Sempre comece atualizando sua cópia local para não trabalhar em cima de uma versão desatualizada:

```bash
git checkout main
git pull
```

### 2. Criar uma branch de trabalho

Crie uma branch com um nome descritivo a partir da `main` atualizada:

```bash
git checkout -b feat/nova-vm-portal
```

O nome da branch deve seguir os padrões definidos na seção abaixo.

### 3. Fazer alterações

Edite os arquivos necessários com seu editor de preferência.

### 4. Ver o que foi alterado

Antes de commitar, confira o que mudou:

```bash
git status          # lista arquivos modificados
git diff            # mostra as diferenças linha a linha
```

### 5. Registrar as alterações (commit)

Adicione os arquivos que fazem parte da mudança e crie o commit:

```bash
git add caminho/para/arquivo.tf
git commit -m "feat(clusters): adiciona VM para cluster portal"
```

Evite usar `git add .` sem antes revisar o `git status` — você pode incluir arquivos indesejados por acidente.

### 6. Enviar a branch para o GitLab (push)

```bash
git push -u origin feat/nova-vm-portal
```

O `-u origin feat/nome-da-branch` só é necessário no primeiro push. Nos seguintes, basta:

```bash
git push
```

### 7. Abrir o Merge Request

Após o push, o GitLab exibirá um link direto para abrir o MR. Clique nele ou acesse o repositório no GitLab e clique em "Create merge request".

Preencha:
- **Título**: descreva a mudança de forma clara (ex: `feat(clusters): adiciona VM para cluster portal`)
- **Descrição**: explique o que muda e por quê
- **Assignee**: atribua a você mesmo
- **Reviewer**: escolha a pessoa que irá revisar

### 8. Acompanhar o pipeline e revisar

Após abrir o MR, o pipeline de CI roda automaticamente. Aguarde a conclusão e confira o output do job de pré-visualização (`plan` no infra, `diff` no stacks) para verificar se o que será alterado corresponde ao esperado.

### 9. Revisão e aprovação

O revisor deve:
1. Ler a descrição do MR
2. Verificar o output do CI (plan/diff)
3. Fazer perguntas ou solicitar ajustes se necessário
4. Aprovar o MR se estiver tudo correto

**Quem aprovou é quem faz o merge** — não quem abriu o MR. Isso garante uma segunda verificação ativa antes da aplicação.