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.