Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Serviços do Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
Visual Studio 2019 | Visual Studio 2022
Dica
Você pode usar a IA para ajudar nas tarefas do Azure DevOps. Consulte Ativar assistência de IA com o servidor MCP do Azure DevOps para começar.
O Git mantém automaticamente um histórico de desenvolvimento em uma ramificação vinculando cada novo commit ao seu antecessor. Quando você mescla uma ramificação em outra, o histórico pode se tornar menos simples. Por exemplo, uma mesclagem no-fast-forward combina linhas divergentes de desenvolvimento criando um commit de mesclagem com vários antecessores. Por outro lado, uma rebase git combina linhas divergentes de desenvolvimento sem criar uma confirmação de mesclagem, o que resulta em um histórico de confirmação mais simples, mas perde informações sobre a mesclagem. Sua escolha de tipo de mesclagem provavelmente é influenciada por você querer preservar um registro da mesclagem ou simplificar o histórico de confirmação.
Este artigo discute quando usar um trocar base em vez de uma mesclagem no-fast-forward e fornece procedimentos para as seguintes tarefas:
- Trocar base da sua ramificação local
- Forçar push da sua ramificação local após um trocar base
- Trocar base interativo para combinação por squash de commits locais
Para obter uma visão geral do fluxo de trabalho do Git, consulte o tutorial do Git do Azure Repos.
Pré-requisitos
| Categoria | Requirements |
|---|---|
| Acesso ao projeto | Membro de um projeto. |
| Permissões | - Exibir código em projetos privados: pelo menos acesso básico . - Clonar ou contribuir para o código em projetos privados: membro do grupo de segurança Colaboradores ou permissões correspondentes no projeto. - Definir permissões de branch ou repositório: gerenciar permissões para o branch ou repositório. - Defina políticas de ramificação, verificações de status ou altere a ramificação padrão: permissão Editar políticas para o repositório ou a ramificação, ou associação ao grupo de segurança Administradores do Projeto. - Importar um repositório: membro do grupo de segurança Administradores do Projeto ou da permissão Criar repositório no nível do projeto do Git definida como Permitir. Para obter mais informações, consulte Definir permissões do Repositório do Git. |
| Serviços | Repositórios habilitados. |
| Tools | Optional. Use os comandos az repos: CLI do Azure DevOps. |
| Categoria | Requirements |
|---|---|
| Acesso ao projeto | Membro de um projeto. |
| Permissões | - Exibir código: pelo menos um acesso básico. - Clonar ou contribuir com o código: membro do grupo de segurança Colaboradores ou permissões correspondentes no projeto. |
| Serviços | Repositórios habilitados. |
Trocar base da sua ramificação local
A rebase do Git integra confirmações de um branch de origem ao branch local atual (branch de destino). O ramo de origem permanece inalterado. Para comparação, a rebase do Git e outros tipos de mesclagem são mostrados no diagrama a seguir.
O trocar base do Git sequencia novamente o histórico de commits da ramificação de destino para que ele contenha todos os commits da ramificação de origem, seguido por todos os commits da ramificação de destino desde o último commit comum. Outra maneira de exibi-lo é que uma troca de base reproduz as alterações na ramificação de destino sobre o histórico da ramificação de origem. Notavelmente, a troca de base do Git altera a sequência de confirmações de branch de destino existentes, o que não é o caso das outras estratégias de mesclagem. No diagrama anterior, commit K' contém as mesmas alterações que K, mas tem uma nova ID de confirmação porque ele é vinculado novamente ao commit E em vez de C.
Durante uma rebase, se uma alteração de branch de origem entrar em conflito com uma alteração de branch de destino, o Git solicitará que você resolva o conflito de mesclagem. Você pode resolver conflitos de mesclagem durante uma troca de base da mesma forma que resolve conflitos de mesclagem durante uma mesclagem.
Trocar base X mesclagem no-fast-forward
A troca de base do Git resulta em um histórico de confirmação mais simples, mas menos exato do que uma mesclagem no-fast-forward, também conhecida como mesclagem three-way ou true. Quando você quiser um registro de uma mesclagem no histórico de commits, use uma mesclagem no-fast-forward.
Se você for a única pessoa trabalhando em um recurso ou ramificação de correção de bugs, considere usar uma troca de base para integrar periodicamente o trabalho de ramificação recente main a ele. Essa estratégia ajuda a garantir que você fique ciente do trabalho recente de outras pessoas e resolva prontamente todos os conflitos de mesclagem que surgirem. Ao trocar base, você implementa seu novo recurso sobre o trabalho de ramificação mais recente main, o que ajuda a manter um histórico de commit linear.
Para obter mais informações sobre a rebase do Git e quando usá-la, consulte Rebase vs merge.
Diretrizes de troca de base e forçar push
Se você basear novamente uma ramificação local que você efetuou push anteriormente e, em seguida, executar o comando push padrão do Git novamente, o push falhará. O comando de push do Git padrão aplica uma mesclagem rápida para integrar seu branch local ao branch remoto. Esse comando falhará após uma rebase porque a rebase altera a sequência de commits existentes em seu branch de destino local, fazendo com que ele não corresponda mais ao histórico de seu branch remoto. Nesse cenário, um forçar push terá êxito substituindo a ramificação remota.
Git rebase e force push são ferramentas poderosas, mas tenha estas orientações em mente ao decidir se deve usá-las:
- Não troque a base de uma ramificação local que tenha sido enviada por push e compartilhada com outras pessoas, a menos que você tenha certeza de que ninguém está usando a ramificação compartilhada. Após uma rebase, sua ramificação local não corresponderá mais ao histórico de seu equivalente remoto.
- Não force o push a uma ramificação remota que esteja em uso por outras pessoas, pois sua versão local da ramificação remota não corresponderá mais ao histórico de ramificação remota atualizado.
- Sua equipe deve concordar com os cenários de uso para troca de base e forçar push.
Dica
Para um processo de revisão colaborativa, use uma solicitação de pull para mesclar um novo trabalho na ramificação padrão de um repositório remoto.
Como fazer a troca de base
- Visual Studio 2022
- Visual Studio 2019 – menu Git
- Visual Studio 2019 – Team Explorer
- Linha de Comando do Git
O Visual Studio 2022 fornece uma experiência de controle de versão do Git usando o menu Git , as Alterações do Git e os menus de contexto no Gerenciador de Soluções. O Visual Studio 2019 versão 16.8 também oferece a interface do usuário do Team Explorer do Git. Para obter mais informações, consulte a guia Visual Studio 2019 – Team Explorer .
Escolha o Git > Manage Branches para abrir a janela do Repositório Git .
Na janela repositório Git , clique com o botão direito do mouse no branch de destino e selecione Checkout.
Clique com o botão direito do mouse no ramo de origem e selecione Rebase <ramo de destino> no <ramo de origem>.
O Visual Studio exibirá uma mensagem de confirmação após uma rebase bem-sucedida.
Se a rebase for interrompida devido a conflitos de mesclagem, o Visual Studio notificará você. Você pode resolver os conflitos ou cancelar a rebase e retornar ao estado de pré-rebase.
Forçar push da sua ramificação local após um trocar base
Se você trocar base de uma ramificação local que você efetuou push anteriormente, um push padrão subsequente do Git falhará. Em vez disso, você pode forçar push da sua ramificação local para substituir seu equivalente remoto para que seus históricos de commit correspondam.
Aviso
Nunca force push de uma ramificação na qual outras pessoas estão trabalhando. Para saber mais, consulte Diretrizes de trocar base e forçar push.
Para forçar o envio no Visual Studio, primeiramente você deve habilitar a opção de forçar envio:
Vá para Ferramentas>Opções>Controle de Código-Fonte>Configurações Globais do Git.
Selecione a opção Habilitar push --force-with-lease.
O sinalizador de push --force-with-lease do Git é mais seguro do que o sinalizador --force porque ele não substituirá uma ramificação remota que tenha commits que não estão integrados na ramificação local que você está forçando o envio por push.
- Visual Studio 2022
- Visual Studio 2019 – menu Git
- Visual Studio 2019 – Team Explorer
- Linha de Comando do Git
Na janela Alterações do Git , selecione o botão de push para pressionar sua confirmação.
Ou, você pode selecionar Push no menu Git .
Se a operação de push do Git padrão falhar, o Visual Studio iniciará a caixa de diálogo Git-Push com falha . Escolha Forçar Push.
O Visual Studio exibirá uma mensagem de confirmação após um push bem-sucedido.
Trocar base interativo para combinação por squash de commits locais
Normalmente, à medida que você trabalha em um novo recurso em sua ramificação de recurso local, você criará vários commits. Quando estiver pronto para publicar o novo recurso, convém consolidar essas confirmações em uma única confirmação para simplificar o histórico de confirmação. Você pode usar uma troca de base interativa para combinar por squash vários commits em um único commit.
- Visual Studio 2022
- Visual Studio 2019 – menu Git
- Visual Studio 2019 – Team Explorer
- Linha de Comando do Git
O Visual Studio 2022 não dá suporte ao rebasing interativo. Em vez disso, use a linha de comando do Git.
Observação
Os usuários do Azure DevOps podem fazer mesclagem squash para condensar o histórico de commit de uma ramificação de tópicos durante uma solicitação de pull.