Perguntas frequentes do Git

Primeiro, verifique se você tem um origin repositório configurado. Se você clonou seu repositório com git clone, você já tem um. Quando você faz check-out de um branch que não existe localmente, o Git determina se existe um branch remoto com o mesmo nome. Nesse caso, o Git cria um branch local que faz referência ao branch remoto. Use git pull para baixar os commits e atualizar o histórico do branch localmente.

Execute git branch sem argumentos para mostrar os branches locais e realçar o que você verificou. No Visual Studio, a barra de status exibe o branch atual quando você trabalha com um projeto armazenado em um repositório Git local.

Faça confirmações separadas para alterações logicamente distintas. Pense nos commits como entradas em um livro de registro. Sempre que fizer uma alteração relevante, registre-a em um commit. Uma abordagem popular é permitir commits locais frequentes, mas agrupá-los por meio de rebasing antes de enviar por push. Essa abordagem fornece flexibilidade, mantendo o histórico de confirmação simplificado.

Em projetos grandes, com muitos commits e colaboradores, o histórico da ramificação main pode refletir mais o desenvolvimento das ramificações temáticas do que o progresso geral do projeto. Você pode condensar commits em branches por meio de squash de commits e rebasing. O esmagamento de confirmações simplifica o histórico do branch, o que torna o histórico de confirmação no branch principal mais limpo após a mesclagem.

Use o comando git blame para descobrir quem fez uma alteração específica em um arquivo. No repositório local, execute git blame com o parâmetro -L para especificar as linhas de interesse. Blame produz uma saída formatada que mostra o commit que atualizou a linha pela última vez e o nome da pessoa que fez o commit.

> git blame Example_repo -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Example User 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 22) line 22 of the code

Blame pesquisa o histórico de commits para você. Você também pode examinar o histórico de um arquivo no portal da Web para determinar quem fez uma alteração e quando. Abra o Gerenciador de Códigos para seu repositório e branch e selecione o arquivo de interesse. O Azure Repos mostra o histórico de commit completo do arquivo no branch atual.

A verificação de um branch diferente no Git afeta o estado dos arquivos em seu sistema de arquivos. O Git usa o histórico de commits para garantir que você trabalhe com arquivos que representam o estado do branch. Se você tentar mudar de branch enquanto tiver alterações não confirmadas, essas alterações serão substituídas durante o checkout. Para evitar a perda acidental de alterações, o Git bloqueia o checkout. Você tem estas opções:

• Abandone as alterações e retorne ao commit mais recente. Veja como desfazer alterações no Git para instruções sobre como reverter para o commit mais recente.
• Confirme as alterações. Confira como salvar seu trabalho no Git com commits.
• Guardar alterações do trabalho atual, salvando-as para mais tarde e revertendo a área de trabalho ao último commit.

Esse problema ocorre devido a conflitos de mesclagem em arquivos binários grandes. O limite de tamanho do arquivo atual é de 100 MB. Para contornar esse problema, mesclar o destino na origem localmente, resolver conflitos e efetuar push das alterações.

Use o Git LFS (Armazenamento de Arquivos Grandes) para arquivos binários grandes para evitar conflitos e gerenciar o tamanho geral do repositório, o que afeta os tempos de clonagem e push.

Para salvar as alterações sem confirmá-las, use o Git stash. Esse comando salva as alterações em etapas atuais e não preparadas em seu branch e reverte o branch para o estado da última confirmação. Em seguida, você pode alternar para outra ramificação, concluir seu trabalho e executar stash apply posteriormente para restaurar suas alterações.

git stash
Saved working directory and index state WIP on feature1: be26067 updated endpoint docs
HEAD is now at be26067

Quando você executa git stash apply, as alterações mais recentes armazenadas se aplicam ao branch atual. Se houver um conflito, stash restaurará as alterações para arquivos que não entram em conflito e criará marcadores de conflito em arquivos que entram em conflito. Mescle as alterações manualmente nesse caso.

Depois de terminar com o estoque, exclua-o com git stash drop. Esse comando remove o último conjunto de alterações armazenadas.

Você pode ter vários estoques, mas gerenciá-los requer mais trabalho manual, pois você deve aplicar e descartar explicitamente cada estoque. Para obter mais informações, consulte a documentação do Git Stash.

Por padrão, o Git de linha de comando usa um editor de linha de comando quando solicita mensagens de confirmação, executa rebases e executa outros trabalhos que exigem informações adicionais. Configure o editor padrão com git config:

> git config core.editor _path_to_editor_ _options_to_editor_

O Git para Windows facilita a definição do Bloco de Notas como o editor:

> git config core.editor notepad

Esse comando configura o Bloco de Notas do Windows para editar informações do Git conforme necessário e passar o texto corretamente entre o Git e o Bloco de Notas. Também é possível especificar

> git config format.commitMessageColumns 72 

Essa configuração mantém as colunas de texto em mensagens de confirmação na largura preferencial de 72 caracteres e encapsula linhas nesse limite.

O Git inclui um nome de usuário e um endereço de email em cada confirmação, e o Azure Repos usa essas informações ao exibir confirmações e trabalhar com solicitações de pull. Para atualizar as informações de nome e email na linha de comando, use o git config comando:

> git config --global user.email "example-user@example-site.com"
> git config --global user.name "Example User"

A opção --global define o email e o nome incluídos em commits para todos os repositórios Git nesse sistema. Para alterar as configurações de um único repositório, vá para o diretório onde o repositório Git está localizado e execute os comandos anteriores sem o --global sinalizador.

Também é possível alterar as configurações de nome e email do Visual Studio. No menu Git , selecione Configurações. Na caixa de diálogo Opções, selecione Configurações Globais do Git ou Configurações > do Repositório Git.

O Visual Studio 2019, a partir da versão 16.8, e em versões posteriores, proporciona uma experiência de controle de versão do Git, mantendo a interface de usuário Git do Team Explorer. Para usar o Team Explorer, limpe Ferramentas>Opções>Recursos de Prévia>Nova experiência do usuário do Git na barra de menus. Você pode usar recursos do Git de qualquer interface.

No Team Explorer, escolha Configurações, e abaixo de Git, selecione o link Configurações globais ou Configurações de repositório.

Habilite o rastreamento detalhado para obter informações detalhadas de erro. Defina as seguintes variáveis de ambiente antes de executar o comando Git:

set GIT_TRACE=1
set GIT_TRACE_PACKET=1
set GIT_CURL_VERBOSE=1

A saída de rastreamento ajuda a identificar se a falha está relacionada à conectividade de rede, à configuração de proxy, aos certificados SSL ou à autenticação. Para obter mais informações sobre variáveis de ambiente git, consulte Git Internals – Environment Variables.

Se você estiver por trás de um servidor proxy e o Git não estiver configurado para usá-lo, as operações de clonagem e push falharão com erros de 407, 502 ou "não é possível acessar".

Execute git config --list para verificar se um proxy já está configurado. Caso contrário, defina o proxy globalmente:

> git config --global http.proxy http://proxyUsername:proxyPassword@proxy.server.com:port

Para configurar um proxy somente para uma URL específica:

> git config --global http.https://dev.azure.com.proxy http://proxyUsername:proxyPassword@proxy.server.com:port

Para obter mais informações, consulte a documentação de configuração do Git.

Se suas credenciais alteradas ou armazenadas em cache estiverem obsoletas, as operações de clonagem ou push do Git falharão com erros de autenticação. Redefina o GCM (Git Credential Manager) para resolver o problema:

> git config --global --unset credential.helper
> git config --global credential.helper manager

Você também pode remover credenciais armazenadas em cache diretamente no Gerenciador de Credenciais do Windows:

1. Abra Painel de Controle>Contas de Usuário>Gerenciador de Credenciais.
2. Selecione credenciais do Windows.
3. Localizar e remover entradas para git:https://dev.azure.com/<orgname>.

Como alternativa, use a linha de comando:

> cmdkey /list | findstr "git"
> cmdkey /delete:git:https://dev.azure.com/<orgname>

No macOS, execute git credential reject para limpar as credenciais armazenadas:

echo url=https://dev.azure.com/<orgname> | git credential reject

Depois de limpar as credenciais, tente novamente a operação de clonagem ou push. O Git solicita que você seja reautenticado.

Quando você clona ou faz push para uma instância do Azure DevOps Server que utiliza um certificado autoassinado ou de CA interna, o Git falha com:

fatal: unable to access '...': SSL certificate problem: unable to get local issuer certificate

Opção 1: usar o Windows SChannel (recomendado no Windows)

Configure o Git para usar o repositório de certificados do Windows em vez do conjunto de autoridades de certificação (CA) fornecido pelo OpenSSL. Se o certificado do servidor ou a AC for confiável pelo Windows, nenhuma etapa adicional será necessária:

> git config --global http.sslBackend schannel

Para obter mais informações sobre como configurar o back-end SSL no Visual Studio, consulte as configurações do Git – provedor de rede criptográfica.

Opção 2: Apontar o Git para o certificado da Autoridade Certificadora

Exporte seu certificado de autoridade de certificação raiz ou intermediário como um arquivo codificado em Base-64 e depois indique ao Git onde ele se encontra.

> git config --global http.sslCAInfo C:/Users/<yourname>/my-ca-cert.crt

Você também pode acrescentar o certificado ao pacote de CAs existente do Git (normalmente em C:\Program Files\Git\mingw64\etc\ssl\certs\ca-bundle.crt) em vez de substituir o pacote inteiro.

Para cenários de agente de pipeline com certificados autoassinados, consulte Executar um agente auto-hospedado atrás de um proxy ou com certificados autoassinados.