UM HISTÓRICO QUE EXPLICA
Uma boa mudança conta o que aconteceu e por quê.
Git organiza versões como uma sequência de commits. Cada commit deve representar uma intenção pequena e coerente, para que a equipe consiga revisar, testar, recuperar e aprender com o caminho percorrido.
Histórico
Commits preservam estados do trabalho e relacionam uma alteração à sua finalidade.
Branches
Ramos isolam uma tarefa sem interromper a versão estável usada pela equipe.
Revisão
Pull requests criam espaço para discutir impacto, qualidade e critérios de aceite.
PRÁTICA COM CONTEXTO
Faça a mudança pequena, verifique-a e compartilhe o contexto.
- Atualize seu ponto de partida. Antes de iniciar, sincronize a branch local com a referência compartilhada.
- Crie uma branch por objetivo. O nome deve indicar a tarefa, como
feat/menu-cloud. - Registre commits atômicos. Evite misturar refatoração, correção e funcionalidade sem relação.
- Abra um pull request. Explique o problema, a solução, como testar e os riscos conhecidos.
git switch main
git pull --ff-only
git switch -c feat/menu-cloud
git add pages/infraestrutura-cloud
git commit -m "feat: adiciona trilha de infraestrutura e cloud"
git push -u origin feat/menu-cloudDECISÕES RESPONSÁVEIS
Ferramentas ajudam, mas convenções evitam ruído.
Não use a branch principal como espaço de experimento. Proteja-a com revisão e verificações automáticas. Branches curtas reduzem conflitos e permitem integração frequente.
| Pergunta | Por que importa |
|---|---|
| Esta alteração tem uma única intenção? | Commits pequenos tornam revisão, reversão e rastreabilidade mais seguras. |
| Outra pessoa sabe como validar? | O pull request deve registrar contexto, testes e impacto esperado. |
| O comentário explica o impacto? | Revisão respeitosa melhora o produto e o aprendizado da equipe. |