FAQs do Git

Primeiro, certifique-se de ter um origin repositório configurado. Você deve ter isso se você clonou seu repositório usando git cloneo . Quando você faz check-out de uma ramificação que não existe localmente, o Git verifica se há uma ramificação remota com o mesmo nome. Se houver, o Git cria uma ramificação local que faz referência à ramificação remota. Use git pull para baixar as confirmações e atualizar o histórico da filial localmente.

Execute git branch sem argumentos para mostrar as ramificações locais e destacar a que você fez check-out. No Visual Studio, a barra de status também exibe a ramificação atual quando você está trabalhando com um projeto armazenado em um repositório Git local.

É uma boa prática fazer compromissos separados para alterações logicamente distintas. Pense em commits como entradas em um diário de bordo. Sempre que fizer uma alteração digna de nota, registre-a em um commit. Uma abordagem popular é permitir compromissos locais frequentes, mas esmagá-los através de rebasing antes de empurrar. Isso proporciona flexibilidade enquanto mantém o histórico de confirmação simplificado.

Grandes projetos com muitos compromissos e colaboradores podem resultar em um main histórico de ramificações que reflete o desenvolvimento de ramificações temáticas mais do que o projeto geral. O Git permite que você condense commits em ramificações por meio de squashing commits e rebaseing. O esmagamento de commits torna o histórico do ramo menos detalhado, simplificando o histórico de commit no ramo principal uma vez fundido.

Use o git blame comando para descobrir quem fez uma alteração específica em um arquivo. A partir do repositório local, você pode executar git blame com o -L parâmetro, especificando quais linhas de interesse. Blame produz saída formatada mostrando a confirmação que atualizou pela última vez a linha e o nome da pessoa que fez a confirmação.

> 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 confirmações para você. Também pode rever o histórico de um ficheiro no portal Web para determinar quem fez uma alteração e quando. Abra o Code Explorer para seu repositório e ramificação e, em seguida, selecione o arquivo de interesse. O Azure Repos mostra um histórico de confirmação completo para esse arquivo na ramificação atual.

O check-out para uma ramificação diferente no Git afeta o estado dos arquivos no seu sistema de arquivos. O Git usa o histórico de confirmação para garantir que você esteja trabalhando com os arquivos que representam o estado da sua ramificação. Se você tentar alterar as filiais enquanto tiver alterações não confirmadas, essas alterações serão substituídas durante o checkout. Como o Git não quer que você perca acidentalmente suas alterações, ele impede que o checkout aconteça. Tem duas opções:

• Abandone as mudanças e retorne ao compromisso mais recente. Consulte desfazendo alterações no Git para obter instruções sobre como reverter para a confirmação mais recente.
• Consolide as alterações. Veja como salvar seu trabalho no Git com confirmações.
• Guarde seu trabalho atual, salve as alterações para mais tarde e limpe o espaço de trabalho até a última confirmação.

Esse problema está relacionado a conflitos de mesclagem em arquivos binários grandes. O limite atual para arquivos é de 100MB. A solução alternativa é resolver conflitos de mesclagem localmente mesclando o destino na origem localmente, resolvendo conflitos e empurrando as alterações.

O Git LFS (Large File Storage) é recomendado para armazenar arquivos binários grandes, não apenas para evitar conflitos, mas também para gerenciar o tamanho geral do repositório, o que afeta os tempos de clone e push.

Se você quiser salvar suas alterações sem confirmá-las, use o Git stash. O Stash salva as alterações atuais em estágios e não estágios em sua ramificação e reverte sua ramificação para o estado da última confirmação. Em seguida, você pode alternar para outra ramificação, fazer seu trabalho e, posteriormente, executar stash apply para restaurar as 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 ocultadas mais recentemente são aplicadas à sua ramificação atual. Se houver um conflito, [stash] restaura as alterações para os arquivos que não entram em conflito e cria marcadores de conflito nos arquivos que o fazem. Neste caso, você deve mesclar as alterações manualmente.

Quando terminar o armazenamento, exclua-o com [git stash drop]. Este comando remove o último conjunto de alterações ocultas.

Você pode ter vários stashes, mas gerenciá-los requer mais manipulação manual, pois você tem que aplicar explicitamente e descartar stashes. Saiba mais na documentação do Git Stash.

Por padrão, o Git de linha de comando usa um editor de linha de comando ao solicitar mensagens de confirmação, executar rebases e outros trabalhos que exigem informações adicionais para serem concluídos. O editor padrão é configurado usando git config:

> git config core.editor _path_to_editor_ _options_to_editor_

O Git para Windows facilita a configuração do bloco de notas como editor:

> git config core.editor notepad

Este comando configura o Bloco de Notas do Windows para editar as informações do Git conforme necessário e passar corretamente o texto do Git para o Bloco de Notas. Você também pode especificar

> git config format.commitMessageColumns 72 

Para manter as colunas de texto nas mensagens de confirmação para o 72 preferido e quebra automática de linha depois de atingir esse limite de caracteres em uma linha.

O Git coloca um nome de usuário e informações de endereço de email dentro de cada confirmação, e o Azure Repos usa essas informações ao exibir confirmações e ao trabalhar com solicitações pull. Se você estiver trabalhando na linha de comando, poderá atualizar as informações de nome e e-mail exibidas usando o git config comando:

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

A --global opção define o e-mail e o nome incluídos nas confirmações para todos os repositórios Git neste sistema. Se você quiser alterar as configurações de um único repositório, você deve mudar para o diretório onde o repositório Git está localizado e executar os comandos acima sem o --global sinalizador.

Você também pode 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 Gerais do>Repositório Git.

O Visual Studio 2019 versão 16.8 e versões posteriores fornece uma experiência de controle de versão do Git enquanto mantém a interface do usuário do Team Explorer Git. Para usar o Team Explorer, desmarque Ferramentas>Opções>Visualizar recursos>Nova experiência do usuário do Git na barra de menus. Você pode exercitar os recursos do Git a partir de qualquer interface de forma intercambiável.

No Team Explorer, escolha Configurações e, em Git, selecione o link Configurações Globais ou Configurações do Repositório.