Perguntas frequentes sobre o Git

Primeiro, certifique-se de ter um origin repositório configurado. Você deve ter tal repositório se você clonou git clone) seu repo. Quando você faz check-out de uma ramificação que não existe localmente, o Git determina se há uma ramificação remota com o mesmo nome. Se houver, o Git cria uma ramificação local com uma referência à ramificação remota desse nome. Use git pull para baixar os commits e fazer com que o Git acompanhe o histórico da filial localmente.

git branch sem argumentos mostra as filiais locais e destaca as que você conferiu. 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.

A prática aceite consiste em assumir compromissos separados para alterações logicamente separadas. Pense em commits como entradas em um diário de bordo. Sempre que você fizer uma alteração que valha a pena notar, registre-a em um commit. Uma opção popular é permitir que todos se comprometam localmente o quanto quiserem, mas antes de empurrar os compromissos locais, eles os esmagam primeiro através da rebaseamento. Essa opção oferece aos usuários flexibilidade para fazer confirmações frequentes, mantendo o histórico de confirmações simplificado.

Grandes projetos com muitos compromissos e uma variedade de colaboradores podem resultar em históricos de confirmação para a main ramificação que representa o histórico de desenvolvimento das ramificações do tópico fundidas em main mais do que o histórico de desenvolvimento do projeto geral. O Git fornece uma facilidade para condensar commits em ramificações por meio de squashing commits e rebaseing. Quando você esmaga confirmações, o histórico de confirmações em uma ramificação se torna menos detalhado, o que torna o histórico de confirmações mais simples na ramificação principal depois de mesclada.

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 foo.js -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Francis Totten 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Francis Totten 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Francis Totten 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 mostrará um histórico de confirmação completo para esse arquivo na ramificação atual.

O check-out em uma ramificação diferente no Git afetará o estado dos arquivos em 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.

Às vezes, você quer manter as mudanças, mas não confirmá-las porque elas não estão em um ponto em que você se sinta confortável em fazê-lo. Use o Git stash. O Stash pega as alterações atuais em estágios e não estágios em sua ramificação e salva o trabalho e, em seguida, retorna sua ramificação de volta ao estado da última confirmação. Você pode mudar para a outra ramificação, fazer seu trabalho e, quando retornar a essa ramificação, executar stash apply 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ê executar git stash applyo , as alterações ocultadas mais recentemente serão aplicadas à sua ramificação atual. Se houver um conflito aplicando as alterações ocultas, stash restaurará as alterações para os arquivos que não entram em conflito e criará marcadores de conflito nos arquivos que entram em conflito para você resolver. Neste caso, você deve mesclar as alterações manualmente.

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

Você pode ter vários stashes, mas fazer isso requer mais manipulação manual, pois você tem que aplicar explicitamente e soltar stashes. Saiba mais com a documentação do Git Stash.

Por padrão, o Git de linha de comando usará um editor de linha de comando ao solicitar mensagens de confirmação, executar rebases e outros trabalhos que exijam 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 "frank@fabrikam.com"
> git config --global user.name "Francis Totten"

A --global opção definirá o e-mail e o nome incluídos nos commits 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 doRepositório.