Sou professor de Análise e Desenvolvimento de Sistemas, estou há mais de 20 anos na área de TI, e recentemente preparei um módulo inteiro de Git e GitHub para minha turma. Parecia simples: eu já uso Git há anos, é só passar o conteúdo adiante.
Não foi bem assim.
Decidi rodar, no meu próprio terminal, cada comando que ia ensinar — e, de propósito, provocar os erros que sabia que a turma ia encontrar, só para saber exatamente como explicar cada um quando acontecesse em aula. O resultado foi uma quantidade generosa de mensagens de erro na minha tela, e alguns aprendizados que valem compartilhar.
A tela que trava todo mundo na primeira vez
Rodei git commit sem o -m, e o terminal simplesmente... parou. Sem prompt, sem resposta ao Enter, parecia travado.
Era o Vim, o editor de texto padrão do Git, esperando a mensagem do commit. A saída: i para editar, digitar a mensagem, Esc, :wq e Enter.
Não é um bug. É só um editor que ninguém avisou que ia abrir.
As três fases de um merge que ninguém te conta
Essa foi a que mais me ensinou. Tentei mesclar um branch com conflito de propósito, e fui evoluindo por três erros diferentes, cada um revelando uma parte do que o Git realmente faz internamente:
Fase 1 — conflito aberto. O Git marca o arquivo com <<<<<<<, ======= e >>>>>>>, e recusa qualquer merge novo enquanto isso não for resolvido.
Fase 2 — resolvido, mas sem commit. Depois de editar o arquivo e dar git add, tentei um novo merge e levei um fatal: You have not concluded your merge (MERGE_HEAD exists). O conflito já tinha sumido do arquivo, mas o Git ainda guardava uma referência interna (MERGE_HEAD) esperando o git commit final.
Fase 3 — concluído. Só depois do commit é que o merge realmente termina, e o próximo pode começar.
Até então, eu explicava merge como "um comando só". Agora sei que é um processo de três estados — e faz muito mais sentido assim, tanto pra mim quanto pra quem está aprendendo.
Clonar um repositório dentro do outro
Esse eu fiz sem querer, mas ficou de exemplo. Rodei git clone de dentro da pasta de outro repositório, e o Git avisou: "adding embedded git repository".
Cada pasta .git é uma unidade independente — clonar um projeto dentro de outro cria uma espécie de repositório dentro do repositório, que quebra assim que alguém tenta clonar o de fora. Resolvido com git rm --cached e movendo a pasta para o lugar certo.
Por que valeu a pena
Hoje esses mesmos comandos — branch, merge, commit, resolução de conflito — são parte do dia a dia de projetos reais que venho construindo, incluindo sistemas com autenticação própria, testes automatizados e até integração com IA generativa.
Mas o que fica desse processo não foi só prática técnica. Foi perceber que entender os erros — de propósito, sem pressa, antes de precisar explicar pra alguém — é provavelmente a forma mais rápida de aprender qualquer ferramenta de verdade.
Se você está começando com Git agora: os erros que você vai encontrar não são sinal de que está fazendo errado. São, muito provavelmente, os mesmos que todo mundo encontra — inclusive quem está do outro lado, ensinando.
Top comments (0)