Fluxo de trabalho, boas práticas e armadilhas

Você já conhece os comandos. Esta última aula junta tudo num fluxo de trabalho e apresenta os hábitos que separam um histórico de Git organizado de um bagunçado.

O fluxo do dia a dia

Para cada tarefa nova, o roteiro é sempre parecido:

git switch main
git pull                          # 1. começa atualizado
git switch -c minha-tarefa        # 2. uma branch para cada assunto
# ... edita, roda os testes ...
git add arquivo.py
git commit -m "Adiciona validação do formulário"   # 3. commits pequenos
git push -u origin minha-tarefa   # 4. envia a branch
# 5. abre o pull request no GitHub, revisa, faz o merge
git switch main
git pull                          # 6. traz o resultado do merge
git branch -d minha-tarefa        # 7. apaga a branch usada

Boas mensagens de commit

A mensagem é a documentação do histórico. Boas mensagens têm:

um assunto curto (até uns 50 caracteres) que diz o que o commit faz, no imperativo: “Corrige erro no cálculo da média”;
se necessário, uma linha em branco e um corpo explicando o porquê.

Compare:

Ruim	Bom
`ajustes`	`Corrige erro de divisão por zero na média`
`mudei umas coisas`	`Separa o cálculo de notas em função própria`
`agora vai`	`Corrige caminho do arquivo de configuração`

Muitos projetos usam um prefixo para classificar o commit (padrão Conventional Commits): feat: para funcionalidade nova, fix: para correção, docs: para documentação, refactor: para reorganização de código. Exemplo: fix: corrige divisão por zero na média.

Segredos: a armadilha mais cara

Senhas, tokens de API e chaves privadas nunca entram no repositório. Mantenha-os em um arquivo .env e coloque o .env no .gitignore desde o primeiro commit.

Atenção

Se você commitou um segredo por engano e enviou para o GitHub, apagar o arquivo num commit novo não resolve: ele continua no histórico, e robôs varrem o GitHub procurando exatamente isso. Trate o segredo como vazado: revogue e troque a chave imediatamente, e só depois se preocupe em limpar o histórico.

Versões com tags

Uma tag marca um commit específico como uma versão, como v1.0.0:

git tag v1.0.0
git push origin v1.0.0

No GitHub, as tags viram releases, que você pode baixar e anotar com uma descrição das mudanças.

Do push ao site no ar

O fluxo acima se conecta a algo poderoso: serviços de hospedagem como Cloudflare Pages e Vercel se ligam ao seu repositório e publicam o site sozinhos a cada push na main. É exatamente assim que este site funciona: escrever uma aula é criar um arquivo e enviar com git push. Se o build falhar, a versão anterior continua no ar.

Dica

Próximos passos para explorar: GitHub Actions (automatizar testes a cada push), rebase (uma alternativa ao merge para deixar o histórico linear) e proteção de branches (exigir revisão antes de aceitar mudanças na main).

Exercícios: projeto completo

Exercício

1. Fluxo completo. Crie um projeto pequeno, como um script Python que calcula a média de notas. Faça: README.md, .gitignore, pelo menos três commits, uma branch com uma melhoria, um pull request, o merge e uma tag v1.0.0. Publique tudo no GitHub.

Exercício

2. Reescrevendo. Reescreva estas mensagens de commit ruins em mensagens boas, inventando o contexto: teste, arrumei, mais um commit, final final.

Exercício

3. Desafio. Simule um vazamento: crie um .env com uma senha falsa e commite por engano. Corrija removendo o arquivo do rastreamento (git rm --cached .env), adicione-o ao .gitignore e commite. Depois responda por escrito: por que, se essa senha fosse real e já estivesse no GitHub, isso ainda não seria suficiente?

Com isso você tem a base de Git e GitHub que o mercado espera de quem começa, e que vai usar em todos os outros projetos e cursos.