40 principais perguntas e respostas da entrevista do GIT em 2021

top 40 git interview questions

Perguntas mais populares da entrevista do GIT com respostas e exemplos:

Este tutorial informativo inclui um conjunto das perguntas mais prováveis ​​feitas em entrevistas Git junto com suas respostas descritivas. Essas perguntas certamente irão ajudá-lo a se preparar para qualquer entrevista Git com sucesso.

Quer você seja um novato ou um profissional experiente, essas perguntas da entrevista no Git e respostas detalhadas irão certamente ajudá-lo a enriquecer seu conhecimento do assunto e se destacar em seu trabalho, bem como em entrevistas.

Vamos começar!!

Perguntas mais frequentes da entrevista do GIT

Listados abaixo estão algumas das perguntas mais comuns da entrevista do GIT para sua referência.

P # 1) O que é Git?

Responda: Git é uma ferramenta de controle de versão distribuída. É compatível com fluxos de trabalho não lineares distribuídos, pois oferece garantia de dados para a construção de software de boa qualidade.

Git é gratuito e de código aberto. Pode ser usado para quase qualquer tipo de projeto, seja pequeno ou grande. Git é conhecido por sua grande velocidade e eficiência. Os repositórios Git são muito fáceis de encontrar e acessar. Devido às suas características específicas, o Git é altamente flexível, seguro e compatível com o seu sistema.

P # 2) O que é um Sistema de Controle de Versão distribuído?

Responda: Um VCS distribuído é um sistema que não depende de um servidor central para manter um arquivo de projeto e todas as suas versões. No VCS distribuído, cada colaborador ou desenvolvedor obtém uma cópia local do repositório principal e isso é chamado de clone.

(imagem fonte )

Como você pode ver no diagrama acima, cada colaborador mantém um repositório local em suas máquinas locais. Eles podem confirmar e atualizar os repositórios locais sem problemas.

Usando uma operação pull, um desenvolvedor pode atualizar seu repositório local com as alterações mais recentes do servidor central. Usando a operação push, eles podem enviar suas alterações do repositório local para o servidor central.

P # 3) Quem criou o Git?

Responda: Git foi criado por Linus Torvalds em 2005 na estrada para desenvolver o kernel Linux.

P # 4) Qual linguagem é usada no Git?

Responda: C é a linguagem de programação subjacente na qual o Git é escrito. A linguagem C torna o Git rápido, evitando sobrecargas de tempo de execução vinculadas a outras linguagens de programação de alto nível.

P # 5) Quais são as vantagens / principais recursos do Git?

Resposta: Listados abaixo estão os vários f eatures do Git.

(i) Livre e de código aberto:

O Git é emitido sob a licença de código aberto GPL (General Public License). Você não precisa pagar nada para usar o Git.

É totalmente gratuito. Como é open-source, você pode modificar o código-fonte de acordo com suas necessidades.

(ii) Velocidade:

Como você não é obrigado a se conectar a nenhuma rede para executar todas as ações, ele executa todas as tarefas rapidamente. Obter o histórico da versão de um repositório armazenado localmente pode ser cem vezes mais rápido do que obtê-lo do servidor remoto.

Git é escrito em C, que é a linguagem de programação subjacente que evita sobrecargas de tempo de execução vinculadas a outras linguagens de alto nível.

(iii) Escalável:

Git é altamente escalável. Portanto, se o número de colaboradores aumentar nos próximos tempos, o Git pode facilmente acomodar essa mudança.

Apesar de o Git representar um repositório inteiro, os dados mantidos no lado do cliente são muito pequenos, pois o Git compacta todos os vastos dados por meio de uma técnica de compressão sem perdas.

(iv) Confiável:

Como cada colaborador possui seu próprio repositório local, nas instâncias de travamento do sistema, os dados perdidos podem ser recuperados de qualquer um dos repositórios locais. Em todos os momentos, você terá um backup de todos os seus arquivos.

(v) Seguro:

Git utiliza o SHA1 (Secure Hash Function) para nomear e identificar objetos dentro de seu repositório. Cada artefato e confirmação são somados à verificação e recuperados por meio de sua soma de verificação durante o checkout.

O histórico do Git é salvo de uma maneira que o ID de uma versão específica (um commit em termos de Git) depende do histórico de desenvolvimento total executado até aquele commit. Uma vez que uma versão do arquivo é enviada para o Git, não há como alterá-la sem ser notado.

(vi) Econômico:

No caso de um sistema de controle de versão centralizado, o servidor central deve ser forte o suficiente para atender às solicitações de toda a equipe. Isso não é um problema para equipes menores, no entanto, conforme a equipe se expande, as limitações de hardware do servidor podem ser um impedimento para o desempenho.

No caso de sistemas de controle de versão distribuídos como o Git, os membros da equipe não exigem interação com o servidor esperado quando são obrigados a enviar ou receber alterações. Todo o trabalho pesado ocorre na extremidade do cliente, portanto, o hardware do servidor pode ser mantido bastante simples, certamente.

(vii) Suporta Desenvolvimento Não Linear:

Git fornece ramificação e mesclagem rápida e contém ferramentas específicas para visualizar e percorrer um histórico de desenvolvimento não linear. Uma noção básica no Git é que uma mudança será mesclada com mais frequência do que é escrita, pois é enviada para diferentes revisores.

processo de gerenciamento de defeitos em teste de software

Os ramos do Git são extremamente leves. Um branch no Git refere-se apenas a um único commit. A estrutura completa do branch pode ser criada, com a ajuda dos commits pais.

(viii) Ramificação fácil:

O gerenciamento de filiais por meio do Git é muito direto e fácil. São necessários apenas alguns instantes para criar, excluir e mesclar branches. Ramificações de recursos fornecem um ambiente isolado para cada alteração em sua base de código.

Quando um desenvolvedor precisa começar a trabalhar em algo, independentemente do tamanho do trabalho, ele cria um novo branch. Isso garante que o branch master contenha constantemente um código de qualidade de produção.

(ix) Desenvolvimento Distribuído:

O Git fornece a cada desenvolvedor uma cópia local de todo o histórico de desenvolvimento, mais as alterações são clonadas de um repositório para outro. Essas alterações são introduzidas como ramificações de desenvolvimento adicionadas e podem ser mescladas da mesma maneira que uma ramificação desenvolvida localmente.

(x) Compatibilidade junto com os sistemas ou protocolo atuais:

Os repositórios podem ser publicados através de HTTP, FTP ou um protocolo Git em cima de um soquete simples ou ssh.

P # 6) Como você cria um Repositório no Git?

Responda: Para criar um repositório, você precisa criar um diretório para o projeto, caso ainda não exista, e simplesmente executar o comando “ git init ”. Ao executar este comando, um diretório .git será criado dentro do diretório do projeto, ou seja, agora seu diretório do projeto se transformou em um repositório Git.

P # 7) O que é um diretório .git?

Responda: No momento em que você criar um repositório, encontrará um diretório .git presente dentro dele. Este diretório .git contém todos os metadados do repositório e mantém um registro de todas as mudanças feitas nos arquivos em seu repositório, mantendo um histórico de commits.

Todas as informações referentes a commits, hooks, refs, bancos de dados de objetos, endereços de repositórios remotos, etc. são mantidos dentro desta pasta. Esta é a parte mais importante do Git. Quando você clona qualquer repositório Git em sua máquina local, este .git é o diretório que realmente é copiado.

P # 8) O que acontece se o diretório .git for excluído?

Responda: Se o diretório .git / for excluído, você perderá o controle do histórico do seu projeto. O repositório não estará mais sob controle de versão.

P # 9) Qual comando é usado para escrever uma mensagem de confirmação no Git?

Responda: O comando usado para passar uma mensagem para um git commit é git commit -m “mensagem de confirmação”. A bandeira m é usado para passar uma mensagem de confirmação.

P # 10) O que é o repositório Git básico? Como ele é diferente de um repositório Git padrão / não vazio?

Responda: Repositórios que são criados por meio de git init são os repositórios Git padrão / não vazios.

Na pasta de nível superior desse repositório, você encontrará duas coisas:

1. Um subdiretório .git que mantém todos os metadados e rastreia o histórico de seu repo.
2. Uma árvore de trabalho.

Os repositórios que são criados usando git init –bare são conhecidos como repositórios Git vazios. Eles são usados ​​principalmente para compartilhamento. Eles não contêm nenhuma árvore de trabalho. Eles mantêm o histórico de revisão do git de seu repositório na pasta raiz em vez de colocá-lo dentro da subpasta .git.

Ele apenas contém dados do repositório vazio. É assim que um repositório Git simples é diferente de um repositório Git padrão. Além disso, um repositório vazio não tem um remoto padrão origem repositório, uma vez que serve como um repositório de origem para vários usuários remotos.

Uma vez que um repositório vazio não contém nenhum espaço de trabalho, o git push e git pull comandos não funcionam em um repositório vazio. Você não é obrigado a comprometer nenhuma alteração em um repositório básico.

P # 11) Mencione alguns serviços de hospedagem de repositório Git.

Responda:

• Github
• Pikacode
• Gitlab
• Microsoft VSTS
• BitBucket
• GitEnterprise
• SourceForge
• Plataforma de lançamento
• Perforce
• Pé de Feijão
• Parece que

Q # 12) Cite algumas operações básicas no Git.

Responda: Algumas operações básicas no Git incluem:

• Inicializar
• Adicionar
• Comprometer-se
• Empurre
• Puxar

Q # 13) Cite algumas operações avançadas no Git.

Responda: Algumas operações avançadas no Git são:

• Ramificação
• Mesclando
• Rebasing

P # 14) Como você distinguirá entre Git e SVN?

Responda: Git é um controle de versão distribuído, enquanto o SVN é centralizado. Isso leva a muitas diferenças entre os dois em termos de recursos e funcionalidades.

P # 15) Como você diferenciará o Git do GitHub?

Responda: Git é um sistema de controle de versão de alta qualidade. É distribuído por natureza e é empregado para rastrear mudanças no código-fonte durante o desenvolvimento do software. Possui um modelo de ramificação exclusivo que ajuda a sincronizar o trabalho entre os desenvolvedores e rastrear alterações em quaisquer arquivos.

Os objetivos principais do Git são velocidade e integridade de dados, fornecendo suporte a fluxos de trabalho não lineares distribuídos. Git é instalado e mantido na máquina local, em vez da nuvem.

GitHub é um serviço de hospedagem de repositório Git baseado em nuvem que reúne equipes. Ele oferece uma GUI baseada na web, além de controle de acesso e muitos recursos de colaboração, ferramentas fundamentais de gerenciamento de tarefas para cada projeto.

Além disso, GitHub é um código-fonte aberto, ou seja, o código é mantido em um servidor centralizado e pode ser acessado por todos.

P # 16) O que é um conflito no Git e como resolvê-lo?

Responda: O Git possui um recurso de mesclagem automática que lida com os commits de mesclagem por conta própria, desde que as alterações de código ocorram em linhas diferentes e em arquivos diferentes.

Mas, no caso de competir por commits onde há mudanças nas mesmas linhas de código de um arquivo ou um arquivo foi excluído em um branch, mas existe e foi modificado em outro, o Git é incapaz de resolver automaticamente as diferenças e, portanto, levanta conflito de fusão.

Nesses casos, é necessária sua ajuda para decidir qual código incluir e qual código descartar na mesclagem final.

Um conflito de mesclagem pode ocorrer durante a mesclagem de um branch, rebasing de um branch ou seleção seletiva de um commit. Uma vez que um conflito é detectado, Git destaca a área de conflito e pede para você resolvê-lo. Assim que o conflito for resolvido, você pode prosseguir com a fusão.

Siga as etapas abaixo para resolver um conflito concorrente de fusão de mudança de linha:

1. Abra o Git Bash (linha de comando do Git).
2. Usar CD comando para ir para o repositório Git local que está tendo o conflito de mesclagem.
3. Use o git status comando para produzir a lista de arquivos afetados pelo conflito de mesclagem.
4. Abra o editor de texto que você usa e vá até o arquivo que tem conflitos de mesclagem.
5. Para ver o início do conflito de mesclagem em seu arquivo, procure o marcador de conflito no documento<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>> NOME DA FILIAL.
6. Escolha no caso de você precisar manter apenas as alterações do seu branch, apenas manter as alterações do outro branch ou fazer uma nova alteração, que pode incluir alterações dos dois branches. Apague os marcadores de conflito<<<<<<>>>>>> e faça as alterações necessárias na mesclagem final.
7. Usar git adiciona. comando para adicionar ou preparar suas alterações.
8. Finalmente, use o git commit -m “mensagem” comando para confirmar suas alterações com um comentário.

Para resolver o conflito de mesclagem de arquivo removido, você precisa seguir as etapas abaixo:

1. Abra o Git Bash (linha de comando do Git).
2. Usar CD comando para ir para o repositório Git local que tem o conflito de mesclagem.
3. Use o git status comando para produzir a lista de arquivos afetados pelo conflito de mesclagem.
4. Abra o editor de texto que você usa e vá até o arquivo que tem conflitos de mesclagem.
5. Escolha se deseja manter o arquivo removido. Você pode verificar as últimas alterações feitas no arquivo removido em seu editor de texto.
6. Usar git add comando para adicionar o arquivo removido de volta ao repositório. Ou use vai rm comando para remover o arquivo do seu repositório.
7. Finalmente, use o git commit -m “mensagem” comando para confirmar suas alterações com um comentário.

P # 17) Como você consertará um commit quebrado?

Responda: Para consertar um commit quebrado ou para mudar o último commit, o método mais conveniente é usar o comando “ git commit -amend ' .

Ele permite que você combine mudanças encenadas com o commit anterior como uma alternativa para criar um commit inteiramente novo. Isso substitui o commit mais recente pelo commit alterado.

(imagem fonte )

Por meio desse comando, você também pode editar a mensagem de confirmação anterior sem alterar seu instantâneo.

P # 18) Qual é o uso do git instaweb?

Responda: É um script por meio do qual você pode navegar instantaneamente em seu repositório Git de trabalho em um navegador da web.

Este script configura gitweb e um servidor da web para navegar no repositório local. Ele direciona automaticamente um navegador da web e executa um servidor da web por meio de uma interface em seu repositório local.

P # 19) O que é git is-tree?

Responda: ‘Git is-tree’ significa um objeto de árvore que compreende o modo e o nome de todos os itens junto com o valor SHA-1 do blob ou da árvore.

Q # 20) Existe uma maneira de reverter um commit git que já foi enviado e tornado público?

Responda: Sim, para corrigir ou reverter um commit inválido, existem duas abordagens que podem ser usadas com base no cenário.

Eles estão:

1. A maneira mais óbvia é fazer um novo commit, onde você remove o arquivo inválido ou corrige os erros nele. Uma vez feito isso, você pode enviá-lo para um repositório remoto.
2. Outra abordagem é criar um novo commit para desfazer todas as alterações feitas no commit anterior incorreto. Isso pode ser feito por meio do comando git revert - “ git revert '

Q # 21) Como você diferenciará entre git pull e git fetch?

Responda: Git pull comando puxa todos os novos commits de um branch específico no repositório central e torna o branch de destino em seu repositório local atualizado.

perguntas da entrevista de serviços da web em java

Git fetch também visa a mesma coisa, entretanto, sua funcionalidade subjacente é um pouco diferente. Quando você faz um git fetch, todos os novos commits de um branch específico serão puxados em seu repositório central e essas mudanças serão armazenadas em um novo branch em seu repositório local. Isso é chamado de ramificação obtida.

Se você deseja ver essas mudanças em seu ramo de destino, então você precisa realizar um vá fundir após git fetch. O branch de destino será atualizado com as mudanças mais recentes somente após mesclá-lo com o branch obtido.

Assim, um git pull traz o branch local atualizado com sua versão remota, enquanto um git fetch não altera diretamente seu próprio branch local ou cópia de trabalho sob refs / heads. Git fetch pode ser usado para atualizar seus branches de rastreamento remoto em refs / remotes //.

Em palavras simples, git pull é igual a git fetch seguido por um git merge .

Q # 22) Qual é o uso da área de teste ou indexação no Git?

Responda: Da perspectiva do Git, existem três áreas onde as alterações do arquivo podem ser mantidas, ou seja, diretório de trabalho, área de teste e repositório.

Primeiro, você faz alterações no diretório de trabalho do seu projeto armazenado no sistema de arquivos do seu computador. Todas as alterações permanecem aqui até que você as adicione a uma área intermediária chamada área de teste.

Você pode preparar as mudanças executando git add. comando. Esta área de teste dá a você uma prévia de seu próximo commit e basicamente permite que você ajuste seus commits. Você pode adicionar ou remover alterações na área de teste até que esteja satisfeito com a versão que vai submeter.

Depois de verificar suas alterações e assinar o estágio alterado, você pode finalmente confirmar as alterações. Após a confirmação, eles vão para o repositório local, ou seja, para o diretório .git / objects.

Se você usar a GUI do Git, verá a opção de preparar suas alterações. Na captura de tela abaixo, o arquivo sample.txt está na área de mudanças não planejadas, o que significa que está em seu diretório de trabalho.

Você pode selecionar um arquivo e clicar em ‘mudança de estágio’, então ele será movido para a área de teste. Por exemplo , o arquivo hello.txt está presente na área de alteração de estágio (será confirmada). Você pode verificar suas alterações e, em seguida, fazer uma assinatura, seguida de um commit.

O teste também é conhecido como indexação porque o git mantém um arquivo de índice para controlar as alterações do arquivo nessas três áreas. Os arquivos que são testados estão atualmente em seu índice.

Quando você adiciona alterações à área de teste, as informações no índice são atualizadas. Quando você faz um commit, é realmente o que está no índice que é confirmado, e não o que está no diretório de trabalho. Você pode usar o git status comando para ver o que está no índice.

P # 23) O que é Git Stash?

Responda: GIT stash captura o estado atual do diretório de trabalho e do índice e o mantém na pilha para uso futuro. Ele reverte as mudanças não confirmadas (tanto preparadas quanto não) de seu diretório de trabalho e retorna uma árvore de trabalho limpa.

Você pode trabalhar em outra coisa agora e, quando voltar, poderá reaplicar essas alterações. Portanto, se você deseja alternar de um contexto para outro sem perder as alterações atuais, pode usar o armazenamento.

É útil na troca rápida de contexto, onde você está no meio de uma alteração de código que não deseja confirmar ou desfazer agora e tem outra coisa em que trabalhar. O comando a ser usado é git stash.

P # 24) O que é a queda do Git Stash?

Responda: Quando você não precisar mais de um estoque específico, você pode removê-lo executando comando git stash drop . Se você deseja remover todos os stashes de uma só vez do repositório, você pode executar comando git stash clear .

P # 25) O que é o Git stash se aplica? Como é diferente do Git stash pop?

Responda: Ambos os comandos são usados ​​para reaplicar suas alterações armazenadas e começar a trabalhar de onde você saiu.

No git stash aplicar comando, as alterações serão reaplicadas à sua cópia de trabalho e também serão mantidas no estoque. Este comando pode ser usado quando você deseja aplicar as mesmas alterações armazenadas em vários ramos.

No git stash pop comando, as alterações são removidas do stash e são reaplicadas à cópia de trabalho.

P # 26) Qual é o uso do comando git clone?

Responda: O git clone comando cria uma cópia do repositório Git central existente em sua máquina local.

P # 27) Quando o comando git config é usado?

Responda: O git config comando é usado para definir opções de configuração para a instalação do Git.

Por exemplo, depois de baixar o Git, você precisa usar os comandos de configuração abaixo para configurar o nome de usuário e o endereço de e-mail de confirmação no Git, respectivamente:

$ git config –global user.name “”

$ git config –global user.email “”

Então, principalmente, coisas como o comportamento do repositório, informações do usuário e preferências podem ser configuradas com a ajuda deste comando.

P # 28) Como você identificará se o branch já está mesclado no master?

Responda:

Ao executar os comandos abaixo, você pode saber o status de fusão do branch:

1. git branch –merged master: Isso listará todos os branches que foram renomeados como master.
2. branch git –merged: Isso listará todos os branches que foram mesclados no HEAD.
3. branch git –no-merged: Isso listará todos os ramos que ainda não foram mesclados.

Por padrão, este comando informa o status de fusão apenas das ramificações locais. Se você quiser saber sobre o status de fusão de branch local e remoto, você pode usar -para bandeira. Se você quiser verificar apenas ramos remotos, pode usar -r bandeira.

P # 29) O que são ganchos no Git?

Responda: Git hooks são certos scripts que o Git executa antes ou depois de um evento como commit, push, update ou receive. Você encontrará a pasta ‘hooks’ dentro do diretório .git em seu repositório local. Você encontrará os scripts integrados aqui pre-commit, post-commit, pre-push, post push.

Esses scripts são executados localmente antes ou depois da ocorrência de um evento. Você também pode modificar esses scripts de acordo com suas necessidades e o Git executará o script quando esse evento específico ocorrer.

P # 30) Qual é o uso do git fork? Qual a diferença entre a bifurcação e a clonagem?

Responda: Bifurcar um projeto significa criar uma cópia remota do lado do servidor do repositório original. Você pode renomear esta cópia e começar a fazer um novo projeto em torno disso sem afetar o projeto original. O fork não é o conceito central do Git.

A operação fork é usada pelo fluxo de trabalho Git e essa ideia existe por mais tempo para software livre e de código aberto como o GitHub. Geralmente, depois de criar um fork do projeto, você raramente contribuirá para o projeto pai novamente.

Por exemplo, OpenBSD é um sistema operacional de código aberto semelhante ao Unix que foi desenvolvido pela bifurcação do NetBSD, que é outro sistema operacional de código aberto semelhante ao Unix.

No entanto, na bifurcação, existe uma conexão direta entre sua cópia bifurcada e o repositório original. A qualquer momento, você pode contribuir de volta para o projeto original usando as solicitações pull.

Na cópia bifurcada, todos os dados principais, como códigos e arquivos, são copiados do repositório original, no entanto, branches, solicitações de pull e outros recursos não são copiados. A bifurcação é uma forma ideal de colaboração de código aberto.

A clonagem é essencialmente um conceito Git. Um clone é uma cópia local de qualquer repositório remoto. Quando clonamos um repositório, todo o repositório de origem junto com seu histórico e branches são copiados para nossa máquina local.

Ao contrário da bifurcação, não há conexão direta entre o repositório clonado e o repositório remoto original. Se quiser fazer solicitações de pull e continuar de volta ao projeto original, você deve ser adicionado como um colaborador no repositório original.

A clonagem também é uma ótima maneira de criar um backup do repositório original, pois a cópia clonada também tem todo o histórico de commits.

P # 31) Como você descobrirá quais arquivos foram alterados em um commit específico do Git?

Responda: Ao usar o valor hash de um commit específico, você pode executar o comando abaixo para obter a lista de arquivos que foram alterados em um commit específico:

git diff-tree -r {hash}

Isso listará todos os arquivos que foram modificados e também os arquivos que foram adicionados. O sinalizador -r é usado para listar arquivos individuais junto com seu caminho, em vez de reduzi-los apenas aos nomes de diretório raiz.

Você também pode usar o comando abaixo:

git diff-tree –no-commit-id –name-only -r {hash}

–No-commit-id irá treinar novamente os números hash de commit para vir na saída. Enquanto, -name excluirá os caminhos de arquivo e fornecerá apenas os nomes dos arquivos na saída.

Q # 32) Qual é a diferença entre git checkout (nome do branch) e git checkout -b (nome do branch)?

Responda: O comando git checkout (nome do branch) irá mudar de um ramo para outro.

O comando git checkout -b (nome do branch) irá criar um novo branch e também alternar para ele.

Q # 33) O que é SubGit?

Responda: SubGit é uma ferramenta usada para a migração SVN para Git. É desenvolvido por uma empresa chamada TMate. Ele converte os repositórios SVN em Git e permite que você trabalhe em ambos os sistemas simultaneamente. Ele sincroniza automaticamente o SVN com o Git.

(imagem fonte )

Você pode criar um espelho SVN || Git usando esta ferramenta. O SubGit deve ser instalado em seu servidor Git. Ele detectará todas as configurações de seu repositório SVN remoto, incluindo revisões, branches e tags de SVN, e os converterá em commits Git.

Também preserva o histórico, incluindo o rastreamento de dados de mesclagem.

Q # 34) Você pode recuperar um branch excluído no Git?

Responda: Sim você pode. Para recuperar um branch excluído, você deve saber o SHA de início. SHA ou hash é um ID único que o Git cria com cada operação.

Ao excluir um branch, você obtém o SHA exibido no terminal:

Ramificação excluída (era)

Você pode usar o comando abaixo para recuperar o branch excluído:

git checkout -b

Se você não conhece o SHA para o commit na ponta do seu branch, você pode primeiro usar o ir reflog para saber o valor SHA e, em seguida, aplique o comando de verificação acima para restaurar sua ramificação.

Q # 35) O que é git diff comando? Como é diferente de git status?

Responda: Git diff é um comando multi-uso que pode ser executado para mostrar as diferenças entre dois commits arbitrários, mudanças entre a árvore de trabalho e um commit, mudanças entre a árvore de trabalho e um índice, mudanças entre dois arquivos, mudanças entre o índice e uma árvore, etc.

O git status comando é usado para inspecionar um repositório. Mostra o estado do diretório de trabalho e da área de preparação. Ele listará os arquivos que foram testados, que não foram testados e os arquivos que não foram rastreados.

Q # 36) O que um objeto Commit contém?

Responda: O objeto de confirmação contém o hash do objeto de árvore de nível superior, hash de commits pai (se houver), informações do autor e do committer, data de confirmação e mensagem de confirmação.

Você pode ver isso através do git log comando.

Exemplo:

(imagem fonte )

P # 37) O que é git cherry-pick? Quais são os cenários nos quais o git cherry-pick pode ser usado?

Responda: Escolha git é um comando poderoso para aplicar as mudanças introduzidas por um ou mais commits existentes. Ele permite que você escolha um commit de um branch e aplique em outro.

git cherry-pick commitSha é o comando usado para escolher. commitSha é a referência de commit.

Este comando pode ser usado para desfazer alterações. Por exemplo, se por engano você fez um commit para um branch errado, então você pode verificar o branch correto e escolher o commit ao qual ele deveria pertencer.

Também pode ser usado na colaboração da equipe. Pode haver cenários em que o mesmo código precisa ser compartilhado entre dois componentes do produto. Nesse caso, se um desenvolvedor já escreveu esse código, o outro pode escolher o mesmo.

A escolha seletiva também é útil em hotfixes de bugs, em que um commit de patch pode ser selecionado diretamente no branch master para corrigir o problema o mais rápido possível.

Q # 38) Para que é usado o ‘git reset’? Qual é o modo padrão deste comando?

Responda: Git reset é um comando poderoso para desfazer alterações locais no estado de um repositório Git. Este comando redefine o HEAD atual para o estágio especificado.

Ele redefine o índice e o diretório de trabalho para o estado de seu último commit. O reset do Git tem três modos, ou seja, soft, hard e mixed. O modo padrão de operação é misto.

Q # 39) Qual é a diferença entre ‘HEAD’, ‘working tree’ e ‘index’?

diferença entre a árvore b e a árvore b +

Responda: A árvore de trabalho ou área de trabalho é o diretório que contém os arquivos de origem nos quais você está trabalhando atualmente.

O índice é a área de teste no Git onde os commits são preparados. Ele fica entre o commit e sua árvore de trabalho. O índice Git é um grande arquivo binário que lista todos os arquivos no branch atual, seus nomes, checksums sha1 e timestamps.

Este arquivo está presente em /.git/index. HEAD é a referência ou ponteiro para o último commit no branch de checkout atual.

P # 40) Qual é a diferença entre rebase e mesclar? Quando você deve rebase e quando deve mesclar?

Responda: Os comandos rebase e merge são usados ​​para integrar mudanças de um branch para outro, mas de uma maneira diferente.

Como visto nas duas imagens abaixo, suponha que você tenha commits (isso é antes de mesclar / rebase). Após a fusão, você obterá o resultado como uma combinação de commits. Ele une os históricos de ambos os branches e cria um novo ‘merge commit’ no branch do recurso.

Por outro lado, o rebase moverá todo o branch do recurso para começar na ponta do branch master.

(imagem fonte )

As confirmações serão semelhantes a:

Rebasing não é recomendado para branches públicos, pois cria repositórios inconsistentes. No entanto, rebasing é uma boa opção para agências privadas / desenvolvedores individuais. Não é muito adequado para o modo branch-per-feature. Mas se você tiver um modelo de branch por desenvolvedor, então o rebasing não é prejudicial.

Além disso, o rebase é uma operação destrutiva, portanto, sua equipe de desenvolvimento deve ser habilidosa o suficiente para aplicá-la corretamente. Caso contrário, o trabalho comprometido pode ser perdido.

Além disso, reverter uma mesclagem é mais fácil do que reverter um rebase. Portanto, se você sabe que pode haver possibilidades para a reversão necessária, você deve usar a mesclagem.

A fusão persevera a história como ela é, enquanto o rebase a reescreve. Portanto, se você deseja ver o histórico completamente como ele ocorreu, você deve usar mesclar.

P # 41) Qual é a sintaxe para rebase?

Responda: A sintaxe do comando rebase é git rebase (novo-commit)

P # 42) Como você removerá um arquivo do Git sem realmente removê-lo do seu sistema de arquivos local?

Responda: Você pode usar a opção 'em cache' para isso:

git rm -rf –cached $ FILES

Este comando removerá os arquivos do seu repositório sem excluí-los do disco.

Q # 43) Qual é o padrão de ramificação comum no Git?

Responda: O padrão de ramificação comum é baseado no git-flow. Ele tem dois ramos principais, ou seja, mestre e desenvolvimento.

• O branch master contém o código de produção. Todo o código de desenvolvimento é mesclado no branch master em algum ponto no tempo.
• A ramificação de desenvolvimento contém o código de pré-produção. Quando os recursos são concluídos, eles são mesclados ao branch master, geralmente por meio de um pipeline de CI / CD.

Este modelo também tem alguns ramos de suporte que são utilizados durante o ciclo de desenvolvimento:

• Ramos de recursos / ramos de temas: Eles são usados ​​para desenvolver novos recursos para os próximos lançamentos. Ele pode se ramificar do branch de desenvolvimento e deve ser mesclado de volta ao branch de desenvolvimento. Geralmente, esses ramos existem apenas em repositórios de desenvolvedores, e não na origem.
• Ramos do Hotfix: Eles são usados ​​para liberação de produção não planejada quando há necessidade de corrigir qualquer bug crítico imediatamente na versão de produção ao vivo. Eles podem se ramificar do master e devem ser mesclados de volta ao desenvolvimento e master.
• Ramos de liberação: Eles são usados ​​para a preparação de um novo lançamento de produção. O ramo de lançamento permite que você faça pequenas correções de bugs e prepare metadados para lançamento. Eles podem se ramificar do desenvolvimento e devem ser mesclados de volta ao mestre e desenvolver.

Conclusão

Analisamos as questões importantes que geralmente são feitas durante as entrevistas do Git neste tutorial.

Isso não apenas ajudará você a se preparar para as próximas entrevistas, mas também esclarecerá seus conceitos git.

Tudo de bom para sua entrevista!

Leitura recomendada

• Perguntas e respostas da entrevista
• Algumas perguntas interessantes da entrevista de teste de software
• 40 principais perguntas e respostas da entrevista de programação C
• As 40 perguntas e respostas mais populares da entrevista J2EE que você deve ler
• Perguntas e respostas da entrevista de teste de ETL
• Mais de 20 perguntas e respostas da entrevista de saída mais comumente feitas
• Principais perguntas da entrevista sobre Oracle Forms e Reports
• Algumas perguntas e respostas complicadas de testes manuais