Introdução
Bem-vindo a este guia abrangente sobre perguntas e respostas de entrevistas de Git! Seja você um desenvolvedor iniciante, um engenheiro experiente ou um profissional de DevOps, dominar o Git é crucial para o controle de versão eficaz e o desenvolvimento colaborativo. Este documento foi meticulosamente projetado para equipá-lo com o conhecimento e a confiança necessários para se destacar em entrevistas técnicas, cobrindo tudo, desde conceitos fundamentais e fluxos de trabalho avançados até resolução prática de problemas e melhores práticas. Mergulhe para solidificar sua compreensão do Git, explorar suas complexidades e se preparar para impressionar seus entrevistadores com sua expertise em vários cenários e aplicações.
Conceitos Fundamentais de Git
O que é Git e como ele difere de sistemas de controle de versão centralizados como o SVN?
Resposta:
Git é um sistema de controle de versão distribuído (DVCS), o que significa que cada desenvolvedor possui uma cópia completa do histórico do repositório. Ao contrário de sistemas centralizados (por exemplo, SVN), onde um único servidor detém a cópia autoritativa, o Git permite trabalho offline, operações mais rápidas e capacidades de branching/merging mais robustas devido à sua natureza distribuída.
Explique os três estados principais dos arquivos no Git.
Resposta:
Os três estados principais são: Modificado (arquivo alterado, mas ainda não preparado para commit), Preparado (arquivo marcado para ser incluído no próximo snapshot) e Commit (dados do arquivo armazenados com segurança no banco de dados local). Estes correspondem ao diretório de trabalho, área de preparação (index) e diretório Git, respectivamente.
Qual é o propósito da 'área de preparação' (ou 'index') do Git?
Resposta:
A área de preparação é uma área intermediária onde você prepara seu próximo commit. Ela permite que você selecione seletivamente quais alterações do seu diretório de trabalho deseja incluir no próximo commit, em vez de fazer commit de todos os arquivos modificados de uma vez. Isso oferece controle granular sobre os commits.
Como o Git armazena seus dados? O que é um 'commit object'?
Resposta:
O Git armazena dados como uma série de snapshots, não como uma lista de alterações de arquivos. Um objeto de commit é um snapshot de todo o seu repositório em um ponto específico no tempo. Cada commit contém um ponteiro para o objeto de árvore que representa os arquivos do projeto, metadados (autor, committer, timestamp) e ponteiros para seus commits pais.
O que é um 'branch' no Git e por que eles são úteis?
Resposta:
Um branch no Git é simplesmente um ponteiro leve e móvel para um commit. Eles são úteis porque permitem que os desenvolvedores se afastem da linha principal de desenvolvimento para trabalhar em novos recursos ou correções de bugs sem afetar a base de código estável. Isso possibilita o desenvolvimento paralelo e a experimentação.
Explique a diferença entre 'git fetch' e 'git pull'.
Resposta:
'git fetch' baixa novos dados de um repositório remoto, mas não os integra aos seus arquivos de trabalho locais; ele apenas atualiza seus branches de rastreamento remoto. 'git pull' é essencialmente 'git fetch' seguido por 'git merge' (ou 'git rebase'), o que significa que ele baixa as alterações e, em seguida, as integra automaticamente ao seu branch local atual.
O que é um 'merge conflict' e como resolvê-lo?
Resposta:
Um conflito de merge ocorre quando o Git não consegue combinar automaticamente as alterações de dois branches diferentes porque ambos os branches modificaram as mesmas linhas no mesmo arquivo, ou um excluiu um arquivo que o outro modificou. Para resolvê-lo, você edita manualmente os arquivos em conflito, escolhe as alterações desejadas, em seguida, usa 'git add' nos arquivos resolvidos e 'git commit'.
O que é 'git rebase' e quando usá-lo em vez de 'git merge'?
Resposta:
'git rebase' é um comando que reaplica uma série de commits de um branch para outro, reescrevendo efetivamente o histórico de commits. Você pode usá-lo para manter um histórico linear do projeto, evitar commits de merge ou limpar seus commits locais antes de enviá-los (push). É frequentemente preferido para branches de recursos locais antes de fazer o merge para o branch principal.
Como você pode desfazer alterações no Git? Cite alguns comandos.
Resposta:
Existem várias maneiras de desfazer alterações. 'git reset' pode des-preparar arquivos ou mover o ponteiro HEAD para um commit anterior. 'git revert' cria um novo commit que desfaz as alterações de um commit anterior, preservando o histórico. 'git checkout -- ' descarta as alterações no diretório de trabalho para um arquivo específico.
Qual é o propósito de um arquivo '.gitignore'?
Resposta:
Um arquivo '.gitignore' especifica arquivos intencionalmente não rastreados que o Git deve ignorar. Isso é útil para evitar que arquivos temporários, artefatos de build, arquivos de configuração de IDE ou dados sensíveis sejam acidentalmente incluídos no repositório. Cada linha no arquivo especifica um padrão para arquivos ou diretórios a serem ignorados.
Comandos e Fluxos de Trabalho Avançados de Git
Explique a diferença entre git rebase e git merge.
Resposta:
git merge combina branches criando um novo commit de merge, preservando o histórico. git rebase move ou combina uma sequência de commits para um novo commit base, reescrevendo efetivamente o histórico para criar um histórico de commits linear. O rebase é frequentemente preferido para limpar branches locais antes de fazer o merge.
Quando você usaria git cherry-pick?
Resposta:
git cherry-pick é usado para aplicar um commit específico de um branch para outro. Isso é útil para hotfixes, aplicar um único commit de recurso sem fazer o merge de um branch inteiro, ou quando você precisa mover um commit que foi acidentalmente feito no branch errado.
Descreva o propósito do git reflog.
Resposta:
git reflog registra todas as alterações no HEAD do seu repositório, incluindo commits, merges, rebases e resets. É uma poderosa rede de segurança que permite recuperar commits perdidos ou reverter para estados anteriores, mesmo que eles não sejam mais alcançáveis por nenhum branch ou tag.
Como você reverte um commit que já foi enviado para um repositório remoto?
Resposta:
Para reverter um commit enviado, use git revert <hash-do-commit>. Isso cria um novo commit que desfaz as alterações do commit especificado, preservando o histórico. É mais seguro do que git reset --hard em branches compartilhados porque não reescreve o histórico.
O que é git stash e quando você o usaria?
Resposta:
git stash salva temporariamente as alterações que não estão prontas para serem commitadas, permitindo que você mude de branch ou realize outras operações. Ele salva seus arquivos rastreados modificados e alterações preparadas, e você pode reaplicá-los mais tarde usando git stash pop ou git stash apply.
Explique o conceito de 'squash commit' e como você realizaria um.
Resposta:
Um squash commit combina múltiplos commits em um único commit novo. Isso é útil para limpar o histórico de um branch de recurso antes de fazer o merge, tornando o histórico do projeto mais conciso. Você pode realizá-lo usando git rebase -i <hash-do-commit-antes-do-primeiro-commit-a-ser-squashed> e marcando os commits com 'squash' ou 'fixup'.
Qual é a diferença entre git reset --soft, --mixed e --hard?
Resposta:
--soft move o HEAD, mas mantém as alterações preparadas. --mixed (padrão) move o HEAD e des-prepara as alterações. --hard move o HEAD e descarta todas as alterações no diretório de trabalho e na área de preparação. Cada opção afeta o histórico de commits e o estado do seu diretório de trabalho de maneira diferente.
Como você resolve um conflito de merge durante uma operação de rebase?
Resposta:
Durante um rebase, o Git pausa em cada commit com um conflito. Você resolve o conflito manualmente nos arquivos, usa git add nos arquivos resolvidos e, em seguida, continua o rebase com git rebase --continue. Se você quiser abortar, use git rebase --abort.
Descreva um fluxo de trabalho comum de Git com o qual você está familiarizado (por exemplo, Git Flow, GitHub Flow).
Resposta:
GitHub Flow é um fluxo de trabalho leve baseado em branches. Os desenvolvedores criam branches de recursos a partir do main, fazem alterações, abrem pull requests para revisão e fazem o merge no main após a aprovação. O main está sempre pronto para deploy. Isso promove a entrega contínua e simplifica o branching.
Quando você usaria git bisect?
Resposta:
git bisect é usado para encontrar o commit que introduziu um bug realizando uma busca binária através do histórico de commits. Você marca os commits como 'bom' ou 'ruim', e o Git reduz o intervalo até que o commit causador seja identificado, acelerando significativamente a depuração.
Resolução de Problemas Baseada em Cenários
Você fez vários commits no seu branch feature local, mas percebeu que os dois últimos commits contêm informações sensíveis que não devem ser enviadas (pushed). Como você as remove antes de enviar?
Resposta:
Use git reset --soft HEAD~2 para des-fazer os dois últimos commits, mantendo as alterações preparadas (staged). Em seguida, remova as informações sensíveis e crie um novo commit. Alternativamente, git rebase -i HEAD~3 permite que você 'squash' (esmague) ou 'edite' commits para remover conteúdo.
Você está trabalhando em um branch de recurso e precisa mudar temporariamente para o main para corrigir um bug crítico. Você tem alterações não commitadas no seu branch de recurso. Qual é a maneira mais segura de fazer isso?
Resposta:
Use git stash para salvar suas alterações não commitadas. Isso limpa seu diretório de trabalho, permitindo que você mude de branch. Após corrigir o bug no main, volte para o seu branch de recurso e use git stash pop para reaplicar suas alterações.
Você acidentalmente commitou um arquivo binário grande (por exemplo, um arquivo .zip) no seu repositório, e ele já foi enviado para um remoto. Como você o remove do histórico do repositório?
Resposta:
Isso requer reescrita do histórico. A maneira mais segura é usar git filter-repo (recomendado em vez de git filter-branch) para remover o arquivo de todos os commits. Após executá-lo, faça um push forçado (git push --force-with-lease) para atualizar o remoto, informando os colaboradores sobre a reescrita do histórico.
Você puxou (pulled) alterações do origin/main para o seu branch main local, mas agora seu main local tem conflitos de merge. Você percebe que puxou muito cedo e quer reverter para o estado anterior ao pull. Como?
Resposta:
Se o pull criou um commit de merge, use git reset --hard HEAD~1 para reverter para o commit anterior ao merge. Se foi um fast-forward, use git reflog para encontrar o hash do commit anterior ao pull e, em seguida, git reset --hard <hash-do-commit>.
Um colega enviou (pushed) um commit para o main que introduziu um bug. Você precisa reverter apenas aquele commit específico sem afetar os commits subsequentes. Como você faz isso?
Resposta:
Use git revert <hash-do-commit>. Isso cria um novo commit que desfaz as alterações introduzidas pelo commit especificado. É seguro para histórico compartilhado, pois não reescreve o histórico.
Você está tentando enviar (push) seu branch feature local, mas o Git rejeita o push porque o remoto tem novos commits. Você quer incorporar essas alterações e, em seguida, enviar seu trabalho, mantendo seus commits no topo.
Resposta:
Use git pull --rebase. Isso busca as alterações remotas e, em seguida, reaplica seus commits locais no topo do branch remoto atualizado. Isso evita a criação de um commit de merge e mantém um histórico linear.
Você fez commits no seu branch feature local, mas percebeu que eles pertencem a um novo branch diferente. Como você move esses commits para um novo branch e reseta seu branch atual?
Resposta:
Primeiro, crie e mude para o novo branch: git branch novo-branch-feature e git checkout novo-branch-feature. Em seguida, resete seu branch feature original para o estado anterior a esses commits: git checkout feature seguido por git reset --hard HEAD~N (onde N é o número de commits a serem movidos).
Você precisa fazer cherry-pick de um único commit do branch de um colega (their-feature) para o seu branch atual my-feature. Como você faz isso?
Resposta:
Primeiro, certifique-se de estar no seu branch my-feature. Em seguida, use git cherry-pick <hash-do-commit-de-their-feature>. Pode ser necessário buscar o branch dele primeiro se ele não estiver local: git fetch origin their-feature.
Você fez um commit, mas esqueceu de adicionar um arquivo a ele. Você quer incluir esse arquivo no commit anterior sem criar um novo.
Resposta:
Adicione o arquivo esquecido à área de preparação: git add <arquivo-esquecido>. Em seguida, altere o commit anterior: git commit --amend --no-edit. Isso atualiza o último commit com o novo arquivo sem alterar sua mensagem.
Seu branch main está à frente do origin/main por vários commits que não deveriam ter sido enviados (pushed). Você quer forçar seu main local a corresponder exatamente ao origin/main.
Resposta:
Primeiro, certifique-se de que seu main local esteja selecionado (checked out). Em seguida, use git reset --hard origin/main. Isso descartará todos os commits locais no main que não estão no origin/main e resetará seu diretório de trabalho para corresponder ao remoto.
Aplicações de Git Específicas para Funções
Como Engenheiro de DevOps, como você usaria o Git para gerenciar configurações de infraestrutura como código (IaC) e garantir a consistência entre ambientes?
Resposta:
Eu armazenaria configurações de IaC (por exemplo, Terraform, Ansible) em repositórios Git, usando branches para diferentes ambientes (dev, staging, prod). Tags Git marcariam releases estáveis, e pull requests imporiam revisão por pares e testes automatizados antes de mesclar (merge) alterações, garantindo consistência e rastreabilidade.
Para um Desenvolvedor Frontend, descreva como você usaria o Git para gerenciar branches de recursos, lidar com bibliotecas de componentes de UI e integrar com sistemas de design.
Resposta:
Eu criaria branches de recursos para novos componentes de UI ou páginas. Para bibliotecas de componentes, eu usaria submodules Git ou repositórios separados, atualizando-os através de versionamentos. A integração com sistemas de design envolveria puxar (pull) alterações de um repositório ou pacote dedicado de sistema de design, garantindo estilos e componentes consistentes.
Como Desenvolvedor Backend, como você gerencia migrações de esquema de banco de dados usando Git, especialmente em um ambiente de equipe?
Resposta:
Scripts de migração de esquema de banco de dados são versionados no Git junto com o código da aplicação. Cada migração é um arquivo separado, e as alterações são revisadas via pull requests. Ferramentas como Flyway ou Liquibase são usadas para aplicar migrações, com seu estado também rastreado, garantindo que todos os membros da equipe apliquem as migrações na ordem correta.
Se você for um Gerente de Release, como você aproveitaria o Git para versionamento, hotfixes e gerenciamento de múltiplas linhas de release?
Resposta:
Eu usaria tags Git para marcar releases oficiais (por exemplo, v1.0.0). Hotfixes seriam aplicados a um branch hotfix dedicado ou diretamente ao branch de release, e depois feitos cherry-pick de volta para main/develop. Múltiplas linhas de release são gerenciadas mantendo branches separados de longa duração para cada versão principal.
Como Engenheiro de QA, como você usaria o Git para rastrear casos de teste, gerenciar dados de teste e relatar bugs de forma eficaz?
Resposta:
Casos de teste e scripts de automação são versionados no Git. Dados de teste podem ser gerenciados em arquivos separados rastreados pelo Git ou gerados dinamicamente. Relatórios de bugs referenciariam commits ou branches Git específicos onde o problema foi encontrado, auxiliando os desenvolvedores na reprodução e depuração.
Para um Cientista de Dados, como você usa o Git para gerenciar notebooks, conjuntos de dados (ou referências a eles) e versões de modelos?
Resposta:
Eu versionaria notebooks Jupyter e scripts Python no Git. Grandes conjuntos de dados geralmente não são armazenados diretamente, mas referenciados via Git LFS ou armazenamento externo. Versões de modelos são rastreadas armazenando artefatos de modelo (ou seus hashes) e o código que os gerou, vinculando-os a commits Git específicos.
Como Escritor Técnico, como você usa o Git para gerenciar documentação, colaborar com desenvolvedores e lidar com versionamento para diferentes releases de produto?
Resposta:
Eu armazenaria a documentação em Markdown ou AsciiDoc dentro de repositórios Git. Eu colaboraria usando pull requests para revisões e contribuições de desenvolvedores. O versionamento para diferentes releases de produto é tratado criando branches de documentação junto com o código, ou usando tags Git para marcar versões de documentação correspondentes aos releases de produto.
Descreva como um Engenheiro de Segurança usaria o Git para gerenciar políticas de segurança, linhas de base de configuração e auditar alterações.
Resposta:
Políticas de segurança e linhas de base de configuração (por exemplo, para firewalls, hardening de SO) são versionadas no Git. Todas as alterações são feitas via pull requests, exigindo revisão e aprovação por pares. O histórico de commits do Git fornece uma trilha de auditoria imutável de quem mudou o quê, quando e por quê, crucial para conformidade e resposta a incidentes.
Desafios Práticos e "Hands-on"
Você fez vários commits no seu branch feature, mas percebeu que os dois últimos commits deveriam estar em um branch diferente. Como você os moveria?
Resposta:
Use git reset --hard HEAD~2 no branch feature para remover os dois últimos commits. Em seguida, crie um novo branch a partir do estado original antes do reset (por exemplo, git branch novo-feature <hash-do-commit-original>) e faça cherry-pick dos dois commits para ele.
Você acidentalmente commitou informações sensíveis (por exemplo, uma chave de API) e a enviou (pushed) para um repositório remoto. Como você a remove do histórico do Git?
Resposta:
Use git filter-repo (recomendado) ou git filter-branch para reescrever o histórico e remover o arquivo. Após a reescrita, faça um push forçado (git push --force) para atualizar o remoto. Informe os colaboradores para re-clonar ou fazer rebase do trabalho deles.
Descreva um cenário onde você usaria git rebase em vez de git merge.
Resposta:
git rebase é preferível quando você deseja um histórico limpo e linear, especialmente antes de mesclar (merge) um branch de recurso no main. Ele reaplica seus commits no topo do branch de destino, evitando commits de merge e tornando o histórico mais fácil de seguir.
Você está trabalhando em um recurso, mas surge um conserto de bug urgente. Você tem alterações não commitadas. Como você muda para o branch main para corrigir o bug sem perder seu trabalho atual?
Resposta:
Use git stash para salvar temporariamente suas alterações não commitadas. Em seguida, mude para main, corrija o bug e comite. Após voltar para o seu branch de recurso, use git stash pop para reaplicar suas alterações.
Como você reverte um commit específico que já foi enviado (pushed), sem afetar os commits subsequentes?
Resposta:
Use git revert <hash-do-commit>. Isso cria um novo commit que desfaz as alterações introduzidas pelo commit especificado, preservando o histórico do projeto e não o reescrevendo.
Você fez um commit, mas esqueceu de adicionar um arquivo. Como você adiciona o arquivo ao commit anterior?
Resposta:
Adicione o arquivo esquecido à área de preparação (git add <arquivo>). Em seguida, use git commit --amend --no-edit para adicionar o arquivo preparado ao commit anterior sem alterar sua mensagem.
Seu branch main local está atrás do main remoto. Como você atualiza seu branch local sem criar um commit de merge?
Resposta:
Use git pull --rebase. Isso busca alterações do remoto e, em seguida, reaplica seus commits locais no topo do branch remoto atualizado, resultando em um histórico linear.
Você precisa revisar as alterações do branch de um colega sem mesclá-lo ao seu branch atual. Como você faria isso?
Resposta:
Use git fetch origin <nome-do-branch-do-colega>:<nome-do-branch-de-rastreamento-local> para buscar o branch dele sem mesclar. Em seguida, você pode usar git diff <nome-do-branch-de-rastreamento-local> ou git log <nome-do-branch-de-rastreamento-local> para revisar as alterações.
Explique a diferença entre git reset --soft, git reset --mixed e git reset --hard.
Resposta:
--soft move o HEAD, mas mantém as alterações preparadas (staged). --mixed (padrão) move o HEAD e des-prepara as alterações. --hard move o HEAD e descarta todas as alterações no diretório de trabalho e na área de preparação, tornando-o destrutivo.
Como você descobriria quem é o autor de uma linha específica de código em um arquivo?
Resposta:
Use git blame <caminho-do-arquivo>. Este comando mostra o commit e o autor para cada linha no arquivo fornecido, ajudando a rastrear o histórico de segmentos de código específicos.
Solução de Problemas de Git
Como você resolve um conflito de merge?
Resposta:
Conflitos de merge ocorrem quando o Git não consegue reconciliar automaticamente as alterações entre dois branches. Eu identifico os arquivos em conflito, edito-os manualmente para escolher as alterações desejadas, removo os marcadores de conflito (<<<<<<<, =======, >>>>>>>) e, em seguida, adiciono (git add) os arquivos resolvidos, seguidos por um git commit.
Que passos você tomaria se o git push falhasse devido a um erro de "non-fast-forward"?
Resposta:
Um erro de "non-fast-forward" significa que o branch remoto tem alterações que não estão no meu branch local. Eu primeiro faria git pull para buscar e mesclar as alterações remotas no meu branch local. Após resolver quaisquer conflitos de merge potenciais, eu tentaria git push novamente.
Você acidentalmente commitou informações sensíveis. Como você as remove do seu histórico do Git?
Resposta:
Para remover informações sensíveis do histórico, eu usaria git filter-branch ou BFG Repo-Cleaner para reescrever o histórico. Para um único arquivo, git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch SEU_ARQUIVO' é uma opção. Isso reescreve o histórico, portanto, só deve ser feito com cautela e comunicação se outras pessoas já puxaram as alterações.
Como você desfaz o último commit sem perder as alterações?
Resposta:
Eu usaria git reset HEAD~1. Este comando move o ponteiro HEAD um commit para trás, mas mantém as alterações do commit desfeito na área de preparação (ou no diretório de trabalho se --soft não for especificado), permitindo-me modificá-las e commitar novamente.
E se você commitou no branch errado?
Resposta:
Se o commit for o último, eu usaria git reset HEAD~1 para des-commitar, depois git stash as alterações. Em seguida, mudaria para o branch correto (git checkout branch-correto), aplicaria as alterações do stash (git stash pop) e as commitaria lá. Alternativamente, git cherry-pick pode mover um commit específico.
Como você recupera um branch excluído?
Resposta:
Se o branch foi excluído recentemente, posso encontrar o hash do último commit no reflog usando git reflog. Assim que tiver o hash do commit, posso recriar o branch a partir desse commit usando git branch <nome-do-branch> <hash-do-commit>.
Você fez vários commits localmente, mas agora percebe que eles deveriam ser combinados em um único commit. Como você faz isso?
Resposta:
Eu usaria o rebase interativo: git rebase -i HEAD~N, onde N é o número de commits a serem combinados. No editor interativo, eu marcaria o primeiro commit como pick e os commits subsequentes como squash ou fixup. Isso os combina em um único commit.
O que significa 'detached HEAD' e como corrigi-lo?
Resposta:
Um estado 'detached HEAD' significa que o HEAD está apontando diretamente para um commit, não para um branch. Isso geralmente acontece ao fazer checkout de um commit específico ou de uma tag remota. Para corrigir, eu criaria um novo branch a partir do estado atual do detached HEAD usando git checkout -b nome-do-novo-branch.
Como você reverte um commit específico que já foi enviado (pushed)?
Resposta:
Eu usaria git revert <hash-do-commit>. Isso cria um novo commit que desfaz as alterações introduzidas pelo commit especificado. É seguro para commits enviados (pushed) porque não reescreve o histórico, preservando a integridade do repositório compartilhado.
Você acidentalmente adicionou um arquivo grande ao seu repositório e o enviou (pushed). Como você o remove e reduz o tamanho do repositório?
Resposta:
Primeiro, use git rm --cached <arquivo-grande> e comite para removê-lo do commit atual. Para removê-lo do histórico, use git filter-branch ou BFG Repo-Cleaner para reescrever o histórico, depois faça um push forçado. Finalmente, execute git gc --prune=now localmente para limpar objetos soltos.
Melhores Práticas e Colaboração com Git
Qual é o propósito de um arquivo .gitignore e quais são algumas entradas comuns que você incluiria?
Resposta:
Um arquivo .gitignore especifica arquivos intencionalmente não rastreados que o Git deve ignorar. Entradas comuns incluem artefatos de build (por exemplo, *.class, target/), diretórios de dependência (por exemplo, node_modules/), arquivos do sistema operacional (por exemplo, .DS_Store) e informações sensíveis (por exemplo, *.env). Ele evita commits acidentais de dados irrelevantes ou privados.
Explique o conceito de um fluxo de trabalho de 'feature branch'. Por que ele é benéfico?
Resposta:
Um fluxo de trabalho de feature branch envolve a criação de um novo branch para cada novo recurso ou correção de bug. Isso isola o trabalho de desenvolvimento, evitando interferências com a base de código principal até que o recurso esteja completo e testado. Ele promove o desenvolvimento paralelo, revisões de código mais fáceis e um branch main ou master estável.
Quando você deve usar git merge versus git rebase para integrar alterações?
Resposta:
git merge integra alterações criando um novo commit de merge, preservando o histórico de commits original. git rebase reaplica commits de um branch em outro, criando um histórico linear ao reescrever os IDs dos commits. Use merge para branches públicos para manter o histórico e rebase para branches locais e privados para manter o histórico limpo antes de enviar (push).
Descreva um fluxo de trabalho típico do Git para contribuir para um projeto de código aberto.
Resposta:
Um fluxo de trabalho típico envolve fazer um fork do repositório, clonar seu fork localmente, criar um novo branch de recurso, fazer alterações, commitar, enviar (push) para seu fork e, em seguida, abrir um pull request para o repositório original. Em seguida, você abordaria o feedback e potencialmente faria rebase/squash nos commits antes de mesclar.
O que são Git hooks e você pode dar um exemplo de como eles podem ser usados?
Resposta:
Git hooks são scripts que o Git executa automaticamente antes ou depois de eventos como commitar, enviar (push) ou receber commits. Eles podem impor políticas ou automatizar tarefas. Por exemplo, um hook pre-commit pode executar linters ou testes para garantir a qualidade do código antes que um commit seja finalizado.
Como você lida com uma situação em que acidentalmente commitou informações sensíveis (por exemplo, chaves de API) e as enviou (pushed) para um repositório remoto?
Resposta:
Primeiro, remova as informações sensíveis dos seus arquivos locais e adicione-as ao .gitignore. Em seguida, use git filter-branch ou BFG Repo-Cleaner para reescrever o histórico e remover os dados sensíveis de todos os commits. Finalmente, faça um push forçado (git push --force) para o remoto e invalide imediatamente as credenciais comprometidas.
Explique a importância de mensagens de commit claras e concisas. Quais elementos uma boa mensagem de commit deve incluir?
Resposta:
Mensagens de commit claras são cruciais para entender o histórico do projeto, depurar e revisar código. Uma boa mensagem de commit deve ter uma linha de assunto concisa (50-72 caracteres) resumindo a alteração, seguida por uma linha em branco e, em seguida, um corpo mais detalhado explicando o quê foi alterado e por quê. Ela deve responder ao 'porquê' a alteração foi feita, não apenas ao 'o quê'.
O que é um 'squash commit' e quando você o usaria?
Resposta:
Um squash commit combina vários commits em um único novo commit. Você o usaria para limpar um histórico de branch de recurso confuso antes de mesclar no main, tornando o histórico do projeto mais legível e conciso. Isso é frequentemente feito durante um rebase interativo (git rebase -i).
Como você resolve um conflito de merge?
Resposta:
Quando ocorre um conflito de merge, o Git marca as seções conflitantes nos arquivos. Você edita manualmente esses arquivos para escolher quais alterações manter, removendo os marcadores de conflito do Git (<<<<<<<, =======, >>>>>>>). Após resolver todos os conflitos, você adiciona (git add) os arquivos modificados e, em seguida, commita (git commit) para completar o merge.
Qual é o propósito das tags do Git e como você as usa?
Resposta:
As tags do Git são usadas para marcar pontos específicos no histórico como importantes, tipicamente para versões de lançamento (por exemplo, v1.0.0). Elas são como marcadores permanentes. Você as cria com git tag <nome-da-tag> (lightweight) ou git tag -a <nome-da-tag> -m 'mensagem' (annotated) e as envia (push) com git push origin --tags.
Descreva o conceito de 'trunk-based development' e suas vantagens.
Resposta:
Trunk-based development é uma prática de gerenciamento de controle de versão onde os desenvolvedores mesclam atualizações pequenas e frequentes em um único branch compartilhado (o 'trunk' ou main). As vantagens incluem integração contínua, loops de feedback mais rápidos, redução de conflitos de merge devido a alterações menores e rollbacks mais fáceis. Requer automação de testes robusta.
Internos e Arquitetura do Git
Quais são os quatro tipos de objetos principais do Git?
Resposta:
Os quatro tipos de objetos principais do Git são blob, tree, commit e tag. Blobs armazenam o conteúdo de arquivos, trees armazenam estruturas de diretórios, commits armazenam snapshots do repositório em um determinado momento e tags marcam pontos específicos no histórico.
Explique a diferença entre um objeto 'blob' e um objeto 'tree' no Git.
Resposta:
Um objeto 'blob' armazena o conteúdo exato de um arquivo, identificado pelo seu hash SHA-1. Um objeto 'tree' representa um diretório, contendo referências a blobs (para arquivos) e outros trees (para subdiretórios), juntamente com seus nomes e modos.
Como o Git garante a integridade e imutabilidade dos dados?
Resposta:
O Git garante a integridade e imutabilidade dos dados usando hashes SHA-1 para cada objeto. O hash é calculado a partir do conteúdo do objeto, o que significa que qualquer alteração no conteúdo resultaria em um hash diferente, detectando assim corrupção ou adulteração.
Descreva os três estados principais dos arquivos no Git.
Resposta:
Os três estados principais dos arquivos no Git são: diretório de trabalho (modificado, mas não preparado), área de preparação (modificado e marcado para o próximo commit) e diretório Git (committado e armazenado no repositório).
Qual é o propósito do diretório '.git'?
Resposta:
O diretório '.git' é o núcleo de um repositório Git. Ele contém todos os objetos necessários (blobs, trees, commits), referências (branches, tags), arquivos de configuração e logs que o Git usa para gerenciar o histórico e o estado do projeto.
Como o Git armazena versões de arquivos de forma eficiente, em vez de cópias completas?
Resposta:
O Git armazena versões de arquivos de forma eficiente, armazenando apenas o conteúdo completo de um arquivo como um blob na primeira vez que ele é adicionado. Alterações subsequentes são armazenadas como novos blobs, e o Git usa compressão delta (packfiles) para armazenar diferenças entre as versões, economizando espaço.
O que é um 'ref' no Git e dê um exemplo.
Resposta:
Um 'ref' (referência) é um ponteiro para um objeto commit. Exemplos comuns incluem branches (por exemplo, refs/heads/main), tags (por exemplo, refs/tags/v1.0) e HEAD. Eles fornecem nomes legíveis por humanos para pontos específicos no histórico de commits.
Explique a que se refere 'HEAD' no Git.
Resposta:
'HEAD' é uma referência simbólica que aponta para a ponta do branch atual em que você está trabalhando. Quando você faz um commit, o objeto commit para o qual HEAD aponta é atualizado. Ele também pode apontar diretamente para um SHA de commit em um estado 'detached HEAD'.
O que é um 'packfile' no Git?
Resposta:
Um 'packfile' é um único arquivo binário no Git que armazena múltiplos objetos Git (blobs, trees, commits) em um formato comprimido e codificado por delta. Isso reduz significativamente o tamanho do repositório e melhora o desempenho, especialmente para históricos grandes.
Como o Git lida com branching internamente?
Resposta:
O Git lida com branching simplesmente criando um novo ponteiro (um ref de branch) para um commit específico. Quando você faz um commit, o ponteiro do branch avança. O branching é leve porque é apenas um novo ponteiro, não uma cópia completa da base de código.
O que é o 'index' (ou staging area) no Git?
Resposta:
O 'index' ou 'staging area' é um snapshot temporário do diretório de trabalho que o Git usa para preparar o próximo commit. É um arquivo binário que lista os arquivos que farão parte do próximo commit, juntamente com seus SHAs-1 de blob.
Descreva a relação entre commits, trees e blobs.
Resposta:
Um objeto commit aponta para um único objeto tree, que representa o snapshot completo dos arquivos e diretórios do repositório naquele commit. Os objetos tree, por sua vez, apontam para objetos blob (para conteúdo de arquivos) e outros objetos tree (para subdiretórios).
Resumo
Navegar efetivamente pelas perguntas de entrevista sobre Git é um testemunho da sua compreensão do controle de versão e da sua prontidão para o desenvolvimento colaborativo. Ao se preparar completamente para cenários comuns e consultas conceituais, você demonstra não apenas proficiência técnica, mas também uma abordagem proativa para a resolução de problemas e o trabalho em equipe. Essa preparação é fundamental para mostrar seu valor a potenciais empregadores.
Lembre-se, a jornada para dominar o Git vai além da entrevista. O aprendizado contínuo e a aplicação prática desses conceitos solidificarão suas habilidades e aprimorarão suas contribuições para qualquer equipe de desenvolvimento. Abrace novos recursos, explore fluxos de trabalho avançados e sempre se esforce para aprofundar sua compreensão – sua carreira agradecerá por isso.
