1. Por que o fluxo importa
Em produção, o problema raramente é “saber Git”. É conseguir mudar código com rastreio, revisão e rollback simples. Um fluxo leve e repetível reduz incidente e acelera entrega.
2. Branches e nomes claros
git checkout main
git pull
git checkout -b feature/orcamento-status
git add -A
git commit -m "feat(orcamentos): status em tempo real"
git push -u origin feature/orcamento-statusPrefira feature/, fix/ e chore/. Evite commits gigantes: um PR pequeno revisa mais rápido e reverte com menos risco.
3. Pull request com checklist
- O que muda e por quê (contexto em 3–5 linhas)
- Como testar (passos ou comando)
- Risco e rollback
- Screenshots se for UI
Proteja main: exige PR, pelo menos 1 aprovação e CI verde antes do merge.
4. Do merge ao deploy
git checkout main && git pull
git tag -a v1.4.2 -m "orcamentos: status em tempo real"
git push origin v1.4.2Ideal: CI faz build + testes e o deploy sobe a partir da tag ou do commit de main. Evite deploy manual “do laptop” em produção.
git revert e abra um PR de correção.5. Checklist final
- main protegida + CI obrigatório
- Branches curtas com nome descritivo
- PR com contexto, teste e rollback
- Deploy a partir de main/tag, não de máquina local
6. Comandos explicados
| Comando | O que faz |
|---|---|
git checkout main | Muda para a branch main. |
git pull | Baixa do remoto as mudanças novas e as integra à branch atual. |
git checkout -b feature/orcamento-status | Cria a branch e já troca para ela. |
git add -A | Coloca no próximo commit todas as mudanças: arquivos novos, alterados e apagados. |
git commit -m "feat(orcamentos): ..." | Registra o commit. A mensagem segue o padrão tipo(escopo): descrição. |
git push -u origin feature/orcamento-status | Envia a branch ao remoto. O -u guarda essa ligação para os próximos push e pull. |
git tag -a v1.4.2 -m "..." | Cria uma tag anotada, que marca a versão com autor, data e mensagem. |
git push origin v1.4.2 | Envia a tag ao remoto, de onde o deploy pode partir. |
git revert | Cria um novo commit que desfaz outro, sem reescrever o histórico. |
| Tipo de commit | Quando usar |
|---|---|
feat | nova funcionalidade |
fix | correção de erro |
chore | tarefas de manutenção, sem mudar o comportamento |
docs | só documentação |
refactor | reorganizar o código sem mudar o resultado |
test | testes |
Tag v1.4.2 | Significado |
|---|---|
| 1 (major) | muda de forma incompatível com a versão anterior |
| 4 (minor) | traz funcionalidade nova, compatível |
| 2 (patch) | corrige erro, compatível |
7. Exemplo: desfazer uma mudança em produção
Em vez de reescrever o histórico da main, o caminho seguro é reverter o commit em uma branch e abrir um PR:
git checkout main && git pull
git checkout -b fix/reverte-status
git revert 3f2a91c
git push -u origin fix/reverte-statusO 3f2a91c é o identificador do commit a desfazer (veja em git log --oneline). O PR de reversão passa pela mesma revisão e pelo mesmo CI, e o histórico continua íntegro.
8. Erros comuns e como resolver
| Sintoma | Causa provável | Solução |
|---|---|---|
git push rejeitado (non-fast-forward) | O remoto tem commits que você ainda não tem. | Rode git pull --rebase, resolva os conflitos e envie de novo. Não use force-push na main. |
| Uma senha ou chave foi commitada | Um arquivo .env ou de configuração entrou no repositório. | Troque a credencial imediatamente e remova o arquivo do histórico. Adicione-o ao .gitignore. |
| O PR ficou enorme e ninguém revisa | Muitas mudanças em uma branch só. | Quebre em PRs pequenos, cada um com um objetivo. |
| Tag criada na versão errada | A tag apontou para um commit antigo. | Crie uma nova tag no commit certo. Evite apagar tags que já foram publicadas. |