Perguntas de Git em entrevista de emprego: 25 perguntas com respostas

Git aparece em quase toda entrevista para desenvolvedor, QA ou engenheiro DevOps: às vezes em um bloco separado, às vezes no meio da conversa ("como você reverteria um release que deu errado?"). Para o entrevistador, importa menos saber flags de cor e mais entender o modelo: o que é um commit, para onde aponta uma branch, o que reescreve o histórico. A seguir, as 25 perguntas mais comuns, com respostas no nível que causa boa impressão.

As perguntas vão das básicas às avançadas. Ao responder na entrevista, sempre que possível dê um exemplo curto da sua prática — isso vale mais do que repetir a documentação.

Perguntas básicas

1. O que é Git e qual a diferença entre um sistema de controle de versão distribuído e um centralizado?

Git é um sistema de controle de versão distribuído: ele guarda o histórico de alterações do projeto e permite que várias pessoas trabalhem nele em paralelo. Em sistemas centralizados (como o SVN), o histórico completo fica em um único servidor, e o desenvolvedor tem só uma cópia de trabalho. No Git, cada clone contém todo o histórico, então commits, branches, consulta ao histórico e merges funcionam localmente e sem rede.

Daí as vantagens práticas: velocidade, trabalho offline, nenhum ponto único de falha. Um servidor como GitHub ou GitLab é, no Git, apenas um acordo do time sobre qual é a cópia "principal", não uma necessidade técnica.

2. Quais são as três áreas de trabalho do Git?

O diretório de trabalho (arquivos no disco), o índice ou staging area (o snapshot preparado do próximo commit) e o repositório local (a pasta .git com o histórico). git add leva alterações do diretório de trabalho para o índice; git commit, do índice para o repositório.

Um bom detalhe extra é mencionar a quarta área, o repositório remoto, e os comandos git push e git fetch, que trabalham com ele.

3. Para que serve o índice, se dá para commitar direto?

O índice permite montar o commit de forma consciente: de dez arquivos alterados, commitar os três que pertencem a uma tarefa e deixar o resto. Com git add -p dá para escolher até trechos dentro de um arquivo.

Essa é a base dos commits atômicos: um commit, uma alteração lógica. Um histórico assim é fácil de ler, revisar, desfazer com revert e transportar com cherry-pick.

4. O que é um commit do ponto de vista interno do Git?

Um commit é um objeto que guarda uma referência a uma árvore (tree) — o snapshot de todos os arquivos do projeto —, referências aos commits pais, autor, committer, datas e mensagem. Ele é identificado por um hash SHA-1 (versões recentes têm suporte experimental a SHA-256) de todo o conteúdo.

A ideia central: o Git guarda snapshots, não diffs. Arquivos não alterados não são duplicados — a árvore simplesmente aponta para o mesmo blob. Como o hash depende do pai, é impossível alterar um commit antigo sem alterar os hashes de todos os seguintes.

5. O que é uma branch e o que é o HEAD?

Uma branch é apenas um ponteiro móvel para um commit, um arquivo em .git/refs/heads/ com um hash dentro. Por isso criar uma branch no Git é instantâneo e não copia nada. A cada novo commit, o ponteiro da branch atual avança para ele.

O HEAD é o ponteiro para onde você está agora; normalmente ele aponta para uma branch (ref: refs/heads/main). Se você mudar para um commit ou tag específico, o HEAD aponta direto para o commit — esse é o estado de detached HEAD.

6. O que é detached HEAD e por que é perigoso?

É o estado em que o HEAD aponta para um commit, e não para uma branch, por exemplo depois de git switch --detach v1.0 ou git checkout a1b2c3d. Dá para ver o código e até commitar, mas os novos commits não pertencem a nenhuma branch.

Se depois você mudar para outra branch, esses commits ficam inalcançáveis e com o tempo são removidos pelo garbage collector. Para salvar o trabalho, crie uma branch: git switch -c fix-from-detached. Se já saiu, o hash pode ser encontrado no git reflog.

7. Qual a diferença entre git fetch e git pull?

git fetch baixa os novos commits e atualiza as remote-tracking branches como origin/main, mas não mexe nas suas branches locais nem nos arquivos. git pull é fetch mais integração: por padrão merge; com a flag --rebase ou a configuração pull.rebase=true, rebase.

Desenvolvedores experientes costumam fazer fetch separado, olhar git log HEAD..origin/main e só então decidir como integrar as alterações.

8. Como funciona o .gitignore e por que um arquivo continua rastreado mesmo estando nele?

O .gitignore define padrões de arquivos que o Git não deve sugerir adicionar: dependências, build, logs, configs locais com segredos. As regras valem apenas para arquivos não rastreados.

Se o arquivo já foi commitado, o ignore não tem efeito sobre ele. É preciso tirá-lo do índice mantendo-o no disco: git rm --cached config.local.php, e commitar essa remoção. Para ver qual regra está sendo aplicada, use git check-ignore -v caminho.

Branches, merge e conflitos

9. O que é um fast-forward merge?

Se a branch de destino não avançou desde a criação da outra branch, no merge o Git simplesmente move o ponteiro dela para o último commit da branch integrada — sem novo commit. O histórico continua linear.

A flag --no-ff força a criação de um commit de merge mesmo nesse caso: assim o histórico mostra que um grupo de commits era uma feature separada. Já a flag --ff-only só permite fast-forward e recusa quando seria necessário um merge de verdade.

10. Como surge um conflito de merge e como resolvê-lo?

O conflito surge quando as mesmas linhas de um arquivo foram alteradas nas duas branches (ou o arquivo foi apagado em uma e alterado na outra) e o Git não consegue decidir sozinho. Ele interrompe o merge e marca os trechos com <<<<<<<, =======, >>>>>>>.

git status                 # lista de arquivos com conflito
# editamos os arquivos, deixando a versão correta
git add app.js
git commit                 # para merge; para rebase — git rebase --continue

Uma boa resposta inclui também a prevenção: branches pequenas, pull frequente da branch principal, acordos de formatação. E ainda git merge --abort, se for preciso recuar.

11. Qual a diferença entre merge e rebase?

O merge une duas branches criando um commit de merge com dois pais; os commits existentes não mudam e o histórico reflete fielmente o trabalho paralelo. O rebase move os commits da sua branch para cima de outra branch, criando cópias com novos hashes; o histórico fica linear.

Regra comum: rebase para organizar a sua branch local antes de publicar, merge para integrar em branches compartilhadas. Fazer rebase de commits publicados, sobre os quais outras pessoas trabalham, gera duplicatas e confusão.

12. O que é rebase interativo e para que serve?

git rebase -i HEAD~5 abre a lista dos cinco últimos commits, onde para cada um dá para escolher uma ação: pick — manter, reword — mudar a mensagem, edit — parar e ajustar, squash e fixup — juntar com o anterior, drop — remover. As linhas podem ser reordenadas.

O cenário típico: antes de um pull request, transformar "wip", "fix typo", "mais um fix" em dois ou três commits com sentido. Uma combinação prática: git commit --fixup=<hash> e depois git rebase -i --autosquash.

13. O que faz o squash merge e quando ele é escolhido?

No squash merge, todos os commits da branch são compactados em um único commit na branch de destino (git merge --squash ou o botão no GitHub/GitLab). A branch principal recebe um commit por feature.

A vantagem é um histórico limpo na main. A desvantagem: perde-se o histórico detalhado dentro da feature, e o Git não considera a branch original integrada, então o git branch -d se recusa a apagá-la sem -D.

14. O que é cherry-pick e quando ele faz sentido?

git cherry-pick <hash> aplica as alterações de um commit na branch atual, criando um novo commit com o mesmo conteúdo, mas hash diferente. O caso clássico é levar a correção de um bug da develop para a branch de release ou hotfix.

Não vale abusar: a mesma correção passa a existir em dois commits, e um merge posterior das branches pode gerar conflitos. A flag -x adiciona à mensagem uma referência ao commit original.

Desfazer alterações e recuperar

15. Qual a diferença entre git reset --soft, --mixed e --hard?

Modo	Ponteiro da branch	Índice	Diretório de trabalho
--soft	move	não muda	não muda
--mixed (padrão)	move	é limpo	não muda
--hard	move	é limpo	é resetado, alterações perdidas

git reset --soft HEAD~3 é prático para refazer os três últimos commits como um só. O --hard é perigoso para alterações não commitadas: nem o reflog as traz de volta.

16. Qual a diferença entre git revert e git reset?

O reset move o ponteiro da branch para trás, na prática reescrevendo o histórico. O revert cria um novo commit que desfaz as alterações do commit indicado e não reescreve nada.

Por isso, para commits publicados em uma branch compartilhada, a resposta certa é revert: o histórico dos colegas não quebra, e o próprio desfazer fica visível no log. Para um commit de merge é preciso indicar o pai principal: git revert -m 1 <hash>.

17. Como recuperar commits depois de um git reset --hard acidental?

Com o git reflog: ele guarda localmente o histórico de movimentos do HEAD e das branches (por padrão as entradas duram cerca de 90 dias). Encontramos a entrada anterior ao comando errado e voltamos:

git reflog
# a1b2c3d HEAD@{0}: reset: moving to HEAD~2
# 9f8e7d6 HEAD@{1}: commit: Adicionar pagamento
git reset --hard 9f8e7d6

Ressalva importante: o reflog salva apenas o que foi commitado. Alterações que nunca entraram em um commit (ou pelo menos em um stash) não podem ser recuperadas pelo Git.

18. Como descartar alterações em um arquivo e tirá-lo do índice?

Os comandos modernos são git restore app.js (voltar o arquivo ao estado do índice) e git restore --staged app.js (tirar do índice mantendo as alterações). Antes se usavam git checkout -- app.js e git reset HEAD app.js; eles continuam funcionando.

19. O que é git stash e quais são as armadilhas?

O git stash guarda temporariamente as alterações não commitadas e limpa o diretório de trabalho — por exemplo, para mudar com urgência para um hotfix. Para trazê-las de volta, use git stash pop ou apply.

Armadilhas: por padrão, arquivos não rastreados não são guardados (precisa de -u); no pop pode haver conflito, e então a entrada não é removida da lista; é fácil esquecer um stash. Para trabalhos longos, é melhor um commit em uma branch separada.

Perguntas avançadas e trabalho em equipe

20. Como encontrar o commit que quebrou uma funcionalidade?

Com o git bisect — uma busca binária no histórico. Você indica um commit sabidamente ruim e um bom, e o Git leva você ao meio do intervalo até achar o culpado em log2(N) passos.

git bisect start
git bisect bad                 # a versão atual está quebrada
git bisect good v2.3.0         # aqui tudo funcionava
# testamos e respondemos good/bad até o Git apontar o commit
git bisect reset

Se houver um script de verificação, o processo é automatizado: git bisect run npm test.

21. Por que git push --force é perigoso e o que usar no lugar?

O --force sobrescreve a branch remota com a sua versão, e os commits que os colegas já tinham enviado somem do servidor. Mais seguro é git push --force-with-lease: ele só sobrescreve a branch se ela estiver no servidor no estado que você viu no último fetch.

Push forçado é normal na sua própria feature branch depois de um rebase; na main e em outras branches compartilhadas, ele costuma ser bloqueado pela proteção de branches no servidor.

22. Quais workflows de Git você conhece?

GitHub Flow: uma branch principal sempre pronta para deploy e feature branches curtas, integradas via pull request depois de review e CI. Git Flow: branches main e develop, mais feature/*, release/* e hotfix/*; indicado para produtos com releases versionados. Trunk-based development: todos integram no trunk com muita frequência, e o que está incompleto fica escondido atrás de feature flags.

Uma resposta forte justifica a escolha: para um serviço web com deploy contínuo, o Git Flow costuma ser excessivo; para uma biblioteca que mantém várias versões, ele se justifica.

23. O que é um pull request e o que se verifica nele?

Um pull request (no GitLab, merge request) é um pedido de merge de uma branch que passa por code review e verificações automáticas de CI antes de ser integrado. É um recurso da plataforma (GitHub, GitLab, Bitbucket), não do Git em si.

Um bom PR é pequeno, resolve uma tarefa, tem descrição clara e está ligado a uma issue no tracker. O revisor avalia correção, legibilidade, testes e se não entraram no PR arquivos indevidos ou segredos.

24. Que regras de boa mensagem de commit você segue?

Título curto (até 50–72 caracteres) no imperativo — "Adicionar validação de e-mail" —, depois uma linha em branco e o corpo explicando o "porquê", não o "o quê" (o que mudou dá para ver no diff). Muitas equipes usam Conventional Commits: feat:, fix:, docs:, refactor:.

Mensagens assim permitem gerar changelog, encontrar rapidamente o que se procura com git log --grep e entender os motivos das mudanças anos depois.

25. O que você faz se enviou sem querer uma senha para o repositório?

Primeiro, revogar e gerar de novo o segredo: ele já está comprometido, mesmo que seja apagado um minuto depois (clones, forks, cache). Depois, parar de rastrear o arquivo, adicioná-lo ao .gitignore e, se necessário, limpar o histórico com ferramentas como git filter-repo, seguido de force push e aviso ao time.

Aqui o entrevistador testa prioridades: o candidato que começa reescrevendo o histórico e esquece de rotacionar a chave está respondendo errado.

Como se preparar para perguntas de Git

A forma mais confiável não é decorar respostas, e sim executar cada cenário na mão em um repositório de teste: criar e resolver um conflito, fazer reset --hard e recuperar pelo reflog, juntar commits com rebase interativo. Em entrevistas de Git é comum receber uma tarefa prática ou ter que desenhar o grafo de commits antes e depois de um comando — se você já fez isso, o desenho sai fácil.

Também vale fazer um teste rápido de Git para se autoavaliar: tente responder sem consulta o que acontece com o histórico depois de git rebase main ou git revert HEAD. Se você responde com segurança "o que muda nas três áreas", a base está lá.

Resumo

Uma entrevista de Git quase sempre se resume a três temas: modelo de dados (commits, branches, HEAD, índice), integração de alterações (merge, rebase, conflitos, fetch e pull) e desfazer com segurança (reset, revert, reflog). Some a isso o entendimento de workflow de equipe e pull request, e você cobre a grande maioria das perguntas. Todos esses cenários, incluindo trabalho em equipe e ferramentas avançadas, são praticados no curso de Git.