Módulo 2: O ciclo do dia a dia
status, add, commit, push, e branch, que é o que separa quem entendeu Git de quem decorou comandos
Aquecimento: 2 perguntas do Módulo 1
1. Qual a diferença entre Git e GitHub?
Git é o programa de controle de versão que roda na sua máquina. GitHub
é um site que hospeda repositórios Git e acrescenta Pull Request, revisão e CI.
2. Por que fazer fork em vez de só clonar?
Porque você não tem permissão de enviar mudanças no repositório de outra pessoa.
O fork cria uma cópia na sua conta, onde você manda, e onde o CI roda com o seu nome.
As três áreas
Este é o modelo mental que faz todo o resto encaixar. Um arquivo modificado passa por três lugares antes de virar história:
seus arquivos área de preparo história local servidor
(working dir) (staging / index) (repositório) (GitHub)
você edita ──git add──→ selecionado ──git commit──→ salvo ──git push──→ publicado
│
└──git pull── o que os outros fizeramA área do meio é a que confunde todo mundo no começo. Ela existe para você escolher o que entra em cada commit: mexeu em cinco arquivos, mas só três fazem parte da mesma ideia? Adicione só esses três, faça o commit, e depois trate os outros dois em separado. Commit é uma unidade de sentido, não um backup do fim do dia.
O ciclo, comando por comando
git status: onde estou?
O comando que você mais vai usar. Rode antes e depois de qualquer coisa: ele diz
em que branch você está, o que foi modificado, o que já está preparado e o que o
Git está ignorando. Na dúvida, git status.
git add: o que entra neste commit
git add trilha-3/test_04_meus_testes.py # um arquivo específico
git add trilha-3/ # tudo dentro de uma pasta
git add . # tudo que mudou (cuidado)
git add . é prático e perigoso: ele varre tudo, inclusive arquivo
temporário e senha que você deixou num arquivo de teste. Prefira nomear os
arquivos enquanto está aprendendo.
git commit: salvar na história
git commit -m "adiciona teste de unicidade de id nas tabelas principais"A mensagem é para a pessoa que vai ler o histórico daqui a seis meses, muitas vezes você. Diga o que a mudança faz, no presente:
| Ruim | Bom |
|---|---|
ajustes | corrige domínio de status aceito no teste de pedidos |
teste | adiciona teste de defeito fechado sem data_fechamento |
agora vai | remove xfail do teste de valor_total após correção do seed |
git push: publicar
git push # envia os commits do branch atual
git push -u origin meu-branch # na primeira vez de um branch novoEnquanto você não dá push, tudo vive só na sua máquina. Depois do push, está no GitHub, e é aí que o CI começa a rodar.
Branch: por que não trabalhar direto na main
Um branch é uma linha paralela de trabalho. Você sai da main,
faz suas mudanças isoladas, e só depois propõe juntar de volta.
main ──●──●──●─────────────●── ← sempre estável, é o que vale
\ /
meu-branch ●──●──●───── ← você trabalha aqui, sem riscogit switch -c teste-unicidade-ids # cria e entra no branch novo
# ... edita, git add, git commit ...
git push -u origin teste-unicidade-ids
(Em Git mais antigo o comando era git checkout -b nome. Os dois
funcionam.)
Por que isso importa pra QA: é o branch que torna possível testar uma
mudança antes de ela entrar no que vale. O CI roda no branch, o Pull
Request mostra o resultado, e a main só recebe o que passou. Sem
branch, todo mundo escreve por cima do mesmo lugar e não existe "antes de entrar".
Trazer o que os outros fizeram
git switch main # volta pro branch principal
git pull # baixa o que mudou no servidorFaça isso antes de criar um branch novo, pra partir da versão mais recente. É o hábito que evita a maior parte dos conflitos.
Ler o que mudou: a parte mais útil pra QA
git diff # o que você mudou e ainda não preparou
git diff --staged # o que está preparado pro commit
git log --oneline -10 # os 10 últimos commits
git log --oneline -- trilha-3/ # só os commits que tocaram nessa pasta
git show a1b2c3d # tudo o que aquele commit mudou
No diff, - (vermelho) é linha removida e + (verde) é
linha adicionada. Saber ler isso é o que permite responder à pergunta que abre
todo trabalho de teste: o que exatamente mudou?
Situações que assustam (e não são graves)
| Situação | O que fazer |
|---|---|
Abriu uma tela estranha de editor no terminal (o vim) | Aconteceu porque você fez git commit sem -m. Aperte Esc, digite :wq e Enter. |
| Commitei no branch errado | Não se desespere: o commit está salvo. Peça ajuda ou pesquise "git cherry-pick", nada foi perdido. |
| Quero descartar o que editei num arquivo | git restore nome-do-arquivo devolve o arquivo ao último commit. Perde o que você escreveu: confira antes. |
CONFLICT (content): Merge conflict in ... | Duas pessoas mudaram a mesma linha. O Git marca o trecho com <<<<<<< / ======= / >>>>>>>: edite o arquivo deixando como deve ficar, apague os marcadores, e faça git add + git commit. |
Push recusado: rejected: fetch first | Alguém publicou algo antes de você. Rode git pull, resolva se houver conflito, e dê push de novo. |
A regra de ouro: commit feito é commit salvo. É muito difícil perder trabalho já commitado no Git, o que se perde é o que nunca foi commitado. Commite com frequência.
Sua vez
Faça o ciclo completo, no seu fork:
git switch mainegit pull- Crie o branch:
git switch -c meu-primeiro-branch - Crie um arquivo
ANOTACOES.mdna raiz e escreva três linhas sobre o que você aprendeu na trilha de Fundamentos git status: veja o arquivo aparecer como não rastreadogit add ANOTACOES.mdegit statusde novo: veja a diferençagit commit -m "adiciona anotações da trilha de fundamentos"git log --oneline -3: encontre o seu commitgit push -u origin meu-primeiro-branch- Abra o seu repositório no GitHub: o branch e o commit devem estar lá
Deixe esse branch publicado: o Módulo 3 começa exatamente dele.
Olhar de QA
O comando que mais vale pra QA neste módulo não é o commit: é o git log restrito a um caminho e o git diff. Eles respondem sozinhos a pergunta que abre todo trabalho de teste: o que exatamente mudou? Enquanto você depende de alguém te contar, a lista que você recebe nunca é a completa.