Git e fluxo de trabalho
O modelo de commits e branches, e as estratégias de integração que as equipes usam.
O que o Git guarda
O Git não guarda diferenças entre versões de arquivos, como muita gente imagina. Cada commit é uma fotografia completa do projeto naquele momento, mais quem fez, quando, uma mensagem e uma referência ao commit anterior (o pai).
commit 3f9c2e1 ← identificado por um hash do conteúdo
autor: Marina <marina@exemplo.com>
data: 10/03/2026 14:02
pai: a81b7d0
mensagem: Corrige cálculo de frete para o interior
conteúdo: a fotografia de todos os arquivosO identificador do commit é um hash calculado a partir de todo esse conteúdo, inclusive do pai. Mudar qualquer coisa, a mensagem, um arquivo ou o pai, produz outro hash. Por isso um commit nunca muda: o que parece "editar" um commit é criar um commit novo no lugar dele.
Branches são ponteiros
Os commits formam uma cadeia, cada um apontando para o pai. Uma branch é só um nome que aponta para um commit. Criar uma branch é criar um ponteiro, e não copiar arquivos.
┌── feature
▼
A ── B ── D
\
C
▲
└── main ◀── HEADO HEAD indica onde você está. Ao fazer um commit, a branch atual avança para o commit novo.
As três áreas
O Git separa o seu trabalho em três lugares:
| Área | O que contém | Como os arquivos chegam lá |
|---|---|---|
| Diretório de trabalho | Os arquivos como estão no disco, com as suas edições | Você edita |
| Área de preparação (index, staging) | O que vai entrar no próximo commit | git add |
| Repositório | Os commits, guardados na pasta .git | git commit |
A área de preparação permite fazer commits pequenos e coesos, mesmo com várias mudanças em andamento: você escolhe exatamente o que entra em cada um.
Local e remoto
Cada cópia de um repositório Git tem o histórico completo. O servidor (GitHub, GitLab, Bitbucket) é só mais uma cópia, combinada como ponto de encontro da equipe.
| Comando | O que faz |
|---|---|
git commit | Grava no repositório local; ninguém mais vê |
git push | Envia os commits locais para o remoto |
git fetch | Baixa os commits novos do remoto, sem mexer no seu trabalho |
git pull | fetch seguido de juntar o que veio com a sua branch |
Juntar trabalho: merge, rebase e squash
Duas pessoas trabalham em paralelo: uma faz dois commits numa branch feature, outra corrige algo na main. Há três formas de juntar esse trabalho, e cada uma produz um histórico diferente. Reproduzimos as três num repositório de teste.
Merge cria um commit que junta as duas linhas. O histórico mostra exatamente o que aconteceu, inclusive o trabalho em paralelo:
* Merge branch 'feature'
|\
| * Adiciona B
| * Adiciona A
* | Corrige app na main
|/
* Primeira versãoRebase reaplica os commits da feature em cima da main atual, como se o trabalho tivesse começado depois. O histórico fica numa linha só:
* Adiciona B
* Adiciona A
* Corrige app na main
* Primeira versãoSquash junta todos os commits da feature num único commit novo:
* Feature A e B
* Corrige app na main
* Primeira versãoOs três terminam com os mesmos arquivos. O que muda é o histórico que fica para quem precisar entendê-lo depois. O nível Soluções compara quando usar cada um.
O histórico não esquece
Como cada commit guarda uma fotografia completa, tudo o que já foi commitado continua no histórico, mesmo depois de apagado num commit seguinte.
Testamos: um arquivo .env com uma senha foi commitado e, no commit seguinte, removido. O arquivo não existia mais no diretório, mas git log -p mostrou a senha na hora. Qualquer pessoa com uma cópia do repositório, ou com acesso a um fork, consegue ler.
Por isso um segredo commitado é um segredo vazado, mesmo que o commit seguinte o remova. O nível Soluções mostra o que fazer.
Para que o histórico serve
Um histórico bem cuidado é uma ferramenta de trabalho, e não só um registro:
| Pergunta | Ferramenta |
|---|---|
| Por que esta linha existe? | git blame mostra o commit que a escreveu; a mensagem dele explica o motivo |
| O que mudou desde o último deploy? | git log v1.4.1..v1.4.2 |
| Qual commit introduziu este defeito? | git bisect testa commits até encontrar o primeiro com defeito |
| Como desfazer a mudança que quebrou produção? | git revert cria um commit que desfaz outro |
Essas ferramentas só ajudam se os commits forem pequenos, coesos e com mensagens que explicam o motivo. Um commit chamado "ajustes" com 40 arquivos não ajuda ninguém a entender nada.
Por que isso importa quando a IA escreve o código
Com a IA escrevendo boa parte do código, o histórico vira o principal registro do porquê das mudanças:
- Commits enormes com tudo o que o assistente gerou numa sessão, sem separação por assunto.
- Mensagens genéricas, como "update" ou "fix", que não dizem o motivo.
- Um arquivo de configuração com credenciais commitado junto com o resto.
- Sugestões de
git reset --hardoupush --forcepara "resolver" um problema, apagando trabalho de outras pessoas. - Conflitos resolvidos aceitando um dos lados inteiro, descartando a mudança do outro.
O próximo nível compara os fluxos de trabalho, as formas de juntar e de desfazer, e o tratamento de segredos.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Git em cinco minutos
Explique em no máximo cinco minutos de leitura como o Git funciona, para alguém que usa só add, commit e push sem entender o que acontece. Cubra só o essencial: o que é um commit, o que é uma branch, as três áreas (diretório de trabalho, preparação e repositório), a diferença entre o repositório local e o remoto, e por que um segredo apagado continua no histórico. Use um desenho em texto. No final, me faça três perguntas curtas para eu verificar se entendi, e corrija as minhas respostas.
O modelo de dados do Git
Quero entender o modelo de dados do Git, para parar de ter medo dos comandos. Aja como um mentor. Pergunte primeiro como eu uso o Git hoje. Conduza assim, uma etapa por vez, com desenhos em texto: 1. O que um commit guarda e por que o hash muda se qualquer coisa mudar. 2. Branches e HEAD como ponteiros. 3. O que acontece com os ponteiros num commit, num checkout e num merge. 4. O que o rebase faz de verdade: commits novos, e não commits movidos. 5. O que é o reflog e por que quase nada se perde. Faça uma pergunta de verificação em cada etapa e espere a minha resposta.
Merge, rebase e squash
Quero entender a diferença entre merge, rebase e squash de verdade. Use um cenário: uma branch feature com dois commits e a main com um commit novo feito em paralelo. Para cada forma de juntar, mostre o grafo do histórico resultante em texto, e explique: 1. Quais commits são criados e quais são preservados. 2. Se o histórico é reescrito. 3. Como desfazer a mudança inteira depois. 4. O efeito no git bisect e no git blame. Depois me descreva três equipes com hábitos diferentes e pergunte qual forma de juntar eu recomendaria para cada uma. Corrija as minhas respostas.
Desfazer sem destruir
Quero aprender a desfazer coisas no Git sem perder trabalho, meu ou dos outros. Explique, com exemplos de comandos, o que fazer em cada situação: 1. Editei um arquivo e quero descartar a edição. 2. Adicionei um arquivo à preparação por engano. 3. Escrevi errado a mensagem do último commit, que ainda não enviei. 4. Fiz dois commits locais que não quero mais. 5. Um commit com defeito já está na main compartilhada. 6. Fiz um reset --hard e perdi um commit. Para cada uma, diga se o comando reescreve o histórico e por que isso importa. Depois me faça três perguntas de cenário e corrija as minhas respostas.