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:
git checkout main
git pull
2. Criar uma branch de trabalho
Crie uma branch com um nome descritivo a partir da 
main atualizada:
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:
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:
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)
git push -u origin feat/nova-vm-portal
O 
-u origin feat/nome-da-branch só é necessário no primeiro push. Nos seguintes, basta:
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:
Ler a descrição do MR
Verificar o output do CI (plan/diff)
Fazer perguntas ou solicitar ajustes se necessário
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.