Aplicar alterações com troca de base

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Visual Studio 2019 | Visual Studio 2022

O Git mantém automaticamente um histórico de desenvolvimento em um branch vinculando cada nova confirmação ao seu antecessor. Quando você mescla um branch em outro, o histórico pode se tornar menos simples. Por exemplo, uma mesclagem sem avanço rápido combina linhas divergentes de desenvolvimento criando uma confirmação de mesclagem com vários predecessores. 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 uma rebase em vez de uma mesclagem sem avanço rápido e fornece procedimentos para as seguintes tarefas:

Basear novamente seu branch local
Forçar o push do branch local após uma nova base
Rebase interativa para esmagar confirmações 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 de permissões para o branch ou repositório. - Alterar o branch padrão: editar permissões de políticas para o repositório. - 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.
Ferramentas	Optional. Use comandos az repos : CLI do Azure DevOps.

Observação

Em projetos públicos, os usuários com acesso ao Stakeholder têm acesso total ao Azure Repos, incluindo exibição, clonagem e contribuição para o código.

Categoria	Requirements
Acesso ao Projeto	Membro de um projeto.
Permissões	- Exibir código: pelo menos 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.

Basear novamente seu branch local

A rebase do Git integra confirmações de um branch de origem ao branch local atual (branch de destino). O branch de origem permanece inalterado. Para comparação, a rebase do Git e outros tipos de mesclagem são mostrados no diagrama a seguir.

Diagrama mostrando as confirmações de antes e depois ao usar a rebase do Git.

O Git rebase reentança o histórico de confirmação do branch de destino para que ele contenha todas as confirmações do branch de origem, seguido por todas as confirmações de branch de destino desde a última confirmação comum. Outra maneira de exibi-lo é que uma rebase reproduza as alterações em seu branch de destino na parte superior do histórico do branch de origem. Notavelmente, a rebase 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 nova base da mesma forma que resolve conflitos de mesclagem durante uma mesclagem.

Rebase vs. fusão sem avanço rápido

O rebasing do Git resulta em um histórico de confirmação mais simples, mas menos exato do que uma mesclagem sem avanço rápido, também conhecida como mesclagem de três vias ou verdadeira . Quando você quiser um registro de uma mesclagem no histórico de confirmação, use uma mesclagem sem avanço rápido.

Se você for a única pessoa trabalhando em um recurso ou branch de bugfix, considere usar uma rebase para integrar periodicamente o trabalho de branch 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 reenviar, você implementa seu novo recurso com base no trabalho de branch mais recente main , o que ajuda a manter um histórico de confirmação linear.

Para obter mais informações sobre a rebase do Git e quando usá-la, consulte Rebase vs merge.

Diretrizes de rebase e force-push

Se você basear novamente um branch local que você já efetuou push e executar o comando de push do Git padrão 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 confirmações existentes em seu branch de destino local, portanto, ele não corresponde mais ao histórico de seu equivalente remoto. Nesse cenário, um push de força terá êxito ao substituir o branch remoto.

A rebase do Git e o push de força são ferramentas poderosas, mas tenha essas diretrizes em mente ao decidir se deseja usá-las:

Não basear novamente uma ramificação local que foi enviada por push e compartilhada com outras pessoas, a menos que você tenha certeza de que ninguém está usando o branch compartilhado. Após uma rebase, sua ramificação local não corresponderá mais ao histórico de seu equivalente remoto.
Não force o push para um branch remoto que esteja em uso por outras pessoas, pois sua versão local do branch remoto não corresponderá mais ao histórico de branch remoto atualizado.
Sua equipe deve concordar com os cenários de uso para rebasear e forçar push.

Dica

Para um processo de revisão colaborativa, use uma solicitação de pull para mesclar novos trabalhos no branch padrão de um repositório remoto.

Como fazer a rebase

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 Git do Team Explorer . 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 branch de origem e selecione Rebase <target-branch> no <branch> 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.

Para integrar as confirmações do branch de origem em um branch de destino, execute o git rebase comando:

git rebase <source branch name> <target branch name>

Se o branch local atual for o branch de destino, você poderá simplificar o comando de rebase para:

git rebase <source branch name>

O Git notificará você se houver conflitos durante a rebase. Você pode resolver os conflitos e, em seguida, executar git rebase --continue, ou executar git rebase --abort para desfazer a rebase e retornar ao estado de pré-rebase.

Forçar o push do branch local após uma nova base

Se você basear novamente um branch local que você já efetuou push, um push git padrão subsequente falhará. Em vez disso, você pode forçar o push do branch local para substituir seu equivalente remoto para que seus históricos de confirmação correspondam.

Aviso

Nunca force a empurrar um branch em que outros estejam trabalhando. Para obter mais informações, consulte Rebase e force as diretrizes de push.

Para forçar o push no Visual Studio, primeiro você deve habilitar a opção forçar push:

Acesse asConfigurações Globais do Git de Controle > doCódigo-Fontede> de >.
Selecione a opção Habilitar push --force-with-lease .

O sinalizador de push --force-with-lease do Git é mais seguro do que o --force sinalizador porque ele não substituirá um branch remoto que tenha confirmações que não estejam integradas no branch local que você está forçando o envio por push.

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.

Dica

Para forçar o envio por push de novas confirmações do branch local para um branch remoto com o mesmo nome:

git push --force-with-lease <remote> <local branch name>

Se o branch que você deseja enviar por push for o branch de check-out, você poderá simplificar o comando force push para:

git push --force-with-lease <remote>

Quando você clona um repositório remoto, o Git atribui o alias origin como abreviação para a URL do repositório remoto clonado. Execute git remote -v para verificar o valor do origin alias. Para adicionar o alias origin manualmente, execute git remote add origin <remote repo url>. Com o alias origin , você pode simplificar ainda mais o comando force push:

git push --force-with-lease origin

Se o branch local atual rastrear um branch originremoto, você poderá abreviar totalmente o comando force push:

git push --force-with-lease

No entanto, o comando de push totalmente abreviado falhará se o branch local não rastrear um branch remoto. Execute git remote show origin para verificar o status rastreado de suas ramificações.

Rebase interativa para esmagar confirmações locais

Normalmente, à medida que você trabalha em um novo recurso em seu branch de recursos local, você criará várias confirmações. 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 rebase interativa para esmagar várias confirmações em uma única confirmação.

O Visual Studio 2022 não dá suporte ao rebasing interativo. Em vez disso, use a linha de comando do Git.

Confira a ramificação local na qual você deseja executar uma rebase interativa.
Confirmar, esconder ou descartar alterações não confirmadas.
Estime o quanto você deseja ir no histórico de confirmação. Você não precisa ser exato, pois poderá escolher confirmações específicas para esmagar quando executar o comando de rebase interativo. Por exemplo, se você quiser esmagar confirmações nas últimas cinco confirmações, execute:
```
git rebase -i HEAD~5
```
O Git abrirá um editor que listará as cinco últimas confirmações, começando com as mais recentes. Por exemplo:
```
pick 7068b09 Update README network switch section
pick 9d247f7 Update README network controller section
pick 5d7ab9f Fix fiber optic transmitter test
pick 7b43f3f Add network switch test
pick 00859d9 Add network controller test
```
Deixe a primeira linha como está. Nas linhas subsequentes, para mesclar uma confirmação com a acima, altere pick para squash. Por exemplo, para combinar as duas principais confirmações e também as duas confirmações inferiores, modifique a lista de confirmação para:
```
pick 7068b09 Update README network switch section
squash 9d247f7 Update README network controller section
pick 5d7ab9f Fix fiber optic transmitter test
pick 7b43f3f Add network switch test
squash 00859d9 Add network controller test
```
Salve e feche o editor. Em seguida, o Git abrirá um novo editor para cada conjunto de confirmações mescladas, solicitando que você insira uma mensagem de confirmação. Para cada conjunto de confirmação, concatena as mensagens de confirmação até uma mensagem e, em seguida, salve e feche o editor. No exemplo anterior, as confirmações esmagadas são condensadas com novas mensagens de confirmação:
```
8fcb88f Update README network sections
ac6d3c0 Fix fiber optic transmitter test
f0aadc3 Add two network tests
```
Mesmo que a confirmação Fix fiber optic transmitter test não tenha sido esmagada, ela tem uma nova ID de confirmação porque agora está vinculada a uma confirmação de antecessor diferente.

Para obter mais informações sobre o rebasing interativo, consulte o modo interativo de rebase do Git.

Observação

Os usuários do Azure DevOps podem realizar a mesclagem para condensar o histórico de confirmação de uma ramificação de tópico durante uma solicitação de pull.

Próximas etapas

Copiar alterações com cherry-pick

Comentários

Esta página foi útil?

Last updated on 2025-12-17