Aplicar alterações com rebase

Serviços de DevOps do Azure | Azure DevOps Server | Azure DevOps Server 2022

Visual Studio 2019 | Visual Studio 2022

O Git mantém automaticamente um histórico de desenvolvimento numa ramificação vinculando cada novo commit ao seu antecessor. Quando você funde um ramo em outro, a história pode se tornar menos simples. Por exemplo, uma mesclagem sem avanço rápido combina linhas de desenvolvimento divergentes criando um commit 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 do tipo de mesclagem provavelmente é influenciada pelo fato de 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:

Rebaseie sua filial local
Fazer push forçado no ramo local após uma rebase
Rebase interativo para esmagar compromissos locais

Para obter uma visão geral do fluxo de trabalho do Git, consulte o tutorial do Azure Repos Git.

Pré-requisitos

Categoria	Requerimentos
Acesso ao projeto	Membro de um projeto .
Permissões	- Ver código em projetos privados: Acesso pelo menos Básico. - Clone ou contribua para o código em projetos privados: Membro do grupo de segurança Contributors ou permissões correspondentes no projeto. - Definir permissões de ramo ou repositório: Gerir permissões para o ramo ou repositório. - Alterar ramificação padrão: Editar políticas e permissões para o repositório. - Importar um repositório: Membro do grupo de segurança Administradores de Projeto ou com permissão de Criar repositório ao nível do projeto Git definida como Permitir. Para obter mais informações, consulte Definir permissões do repositório Git.
Serviços	Repos ativado.
Ferramentas	Opcional. Utilize os comandos az repos: Azure DevOps CLI.

Observação

Em projetos públicos, os usuários com acesso Partes Interessadas têm acesso total aos repositórios do Azure, incluindo visualização, clonagem e contribuição para o código.

Categoria	Requerimentos
Acesso ao projeto	Membro de um projeto .
Permissões	- Visualização de código: Pelo menos acesso básico. - Clone ou contribua para o código: Membro do grupo de segurança Contributors ou com permissões correspondentes no projeto.
Serviços	Repos ativado.

Rebaseie sua filial local

O Git rebase integra confirmações de uma ramificação de origem à sua ramificação local atual (ramificação 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.

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

A rebase do Git resequencia o histórico de confirmações da ramificação de destino para que ela contenha todas as confirmações de ramificação de origem, seguidas por todas as confirmações de ramificação de destino desde a última confirmação comum. Outra maneira de visualizá-lo é que uma rebase reproduz as alterações na ramificação de destino sobre o histórico da ramificação de origem. Notavelmente, a rebase do Git altera a sequência dos commits de ramificação 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 um novo ID de commit porque ele se vincula de volta para commit E em vez de C.

Durante uma rebase, se uma alteração de ramificação de origem entrar em conflito com uma alteração de ramificação de destino, o Git solicitará que você resolva o conflito de mesclagem. Você pode resolver conflitos de fusão durante uma rebase da mesma forma que resolve conflitos de fusão durante uma fusão.

Rebase vs. mesclagem sem avanço rápido

A utilização do rebase no Git resulta em um histórico de commit mais simples, mas menos preciso do que uma fusão sem avanço rápido, também conhecida como fusão de três vias ou verdadeira. Quando 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 uma ramificação de recurso ou correção de bugs, considere usar uma rebase para integrar main periodicamente o trabalho recente da ramificação nela. Essa estratégia ajuda a garantir que você fique ciente do trabalho recente de outras pessoas e resolva prontamente quaisquer conflitos de mesclagem que surjam. Ao rebasear, você implementa seu novo recurso sobre o trabalho de ramificação mais recente main , o que ajuda a manter um histórico de confirmação linear.

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

Diretrizes de rebase e force-push

Caso rebaseie uma ramificação local que já foi enviada e em seguida execute o comando padrão Git push novamente, a operação vai falhar. O comando push padrão do Git aplica uma mesclagem de avanço rápido para integrar sua ramificação local à ramificação remota. Esse comando falhará após uma rebase porque a rebase altera a sequência de confirmações existentes em sua ramificação de destino local, portanto, não corresponde mais ao histórico de sua contraparte remota. Nesse cenário, um push de força será bem-sucedido — substituindo a ramificação remota.

A rebase do Git e o force push são ferramentas poderosas, mas tenha estas diretrizes em mente ao decidir se deseja usá-las:

Não rebaseie 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 rebaseação, sua filial local não corresponderá mais ao histórico de sua contraparte remota.
Não faça um push forçado para uma ramificação remota que esteja em uso por outras pessoas, pois a versão local deles da ramificação remota não corresponderá mais ao histórico da ramificação remota atualizado.
Sua equipe deve concordar com os cenários de uso para rebase e force push.

Sugestão

Para um processo de revisão colaborativa, use uma solicitação pull para mesclar um novo trabalho na ramificação padrão de um repositório remoto.

Como rebasear

O Visual Studio 2022 fornece uma experiência de controle de versão do Git usando o menu Git, Alterações do Git e por meio de menus de contexto no Gerenciador de Soluções. O Visual Studio 2019 versão 16.8 também oferece a interface de usuário do Team Explorer Git. Para obter mais informações, consulte a guia Visual Studio 2019 - Team Explorer .

Escolha Git > Manage Branches para abrir a janela Git Repository .
Na janela Repositório Git , clique com o botão direito do mouse na ramificação de destino e selecione Checkout.
Clique com o botão direito do mouse na ramificação de origem e selecione Rebasear <ramificação> de destino na <ramificação> 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 irá notificá-lo. Você pode resolver os conflitos ou cancelar a rebase e retornar ao estado de pré-rebase.

Para integrar confirmações de ramificação de origem em uma ramificação de destino, execute o git rebase comando:

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

Se sua ramificação local atual for a ramificação de destino, você poderá simplificar o comando rebase para:

git rebase <source branch name>

O Git irá notificá-lo se houver conflitos durante a rebase. Você pode resolver os conflitos e, em seguida, executar git rebase --continueou executar git rebase --abort para desfazer a rebase e retornar ao estado de pré-rebase.

Fazer push forçado no ramo local após uma rebase

Se você rebasear uma ramificação local que você enviou anteriormente, um push Git padrão subsequente falhará. Em vez disso, você pode forçar o push de sua ramificação local a substituir sua contraparte remota para que seus históricos de confirmação correspondam.

Advertência

Nunca force a empurrar um ramo em que os outros estão trabalhando. Para mais informações, consulte Diretrizes de rebase e push forçado.

Para efetuar um push forçado no Visual Studio, deve-se primeiro ativar a opção de push forçado:

Vá para Opções de Ferramentas>>Controle do>Código-Fonte Configurações Globais do Git.
Selecione a opção Ativar push --force-with-lease .

O sinalizador de push --force-with-lease do Git é mais seguro do que o sinalizador --force porque não substituirá uma ramificação remota que tenha commits que não estejam integrados à ramificação local que se está a forçar a enviar.

Na janela Alterações do Git , selecione o botão para pressionar sua confirmação.

Ou, você pode selecionar Push no menu Git .
Se a operação de push padrão do Git falhar, o Visual Studio iniciará a caixa de diálogoGit-Push falha . Escolha Force Push.
O Visual Studio exibirá uma mensagem de confirmação após um envio bem-sucedido.

Sugestão

Para forçar o push de novos commits do seu ramo local para um ramo remoto com o mesmo nome:

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

Se a ramificação que você deseja enviar por push for a ramificação com check-out, você pode 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 que você clonou. Execute git remote -v para verificar o valor do origin alias. Para adicionar o origin alias manualmente, execute git remote add origin <remote repo url>. Com o origin alias, você pode simplificar ainda mais o comando force push:

git push --force-with-lease origin

Se a tua ramificação local atual rastrear uma ramificação remota no origin, poderás abreviar totalmente o comando force push:

git push --force-with-lease

No entanto, o comando push totalmente abreviado falhará se sua filial local não rastrear uma ramificação remota. Corra git remote show origin para verificar o status rastreado de suas filiais.

Rebase interativo para esmagar compromissos locais

Normalmente, ao trabalhar numa nova funcionalidade no seu ramo de funcionalidades local, irá 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ções. Você pode usar uma rebase interativa para agregar vários commits num único commit.

O Visual Studio 2022 não oferece suporte à redefinição de base interativa. Em vez disso, use a linha de comando do Git.

Confira a ramificação local na qual você deseja executar uma rebase interativa.
Confirme, armazene ou descarte quaisquer alterações não confirmadas.
Estime até onde você deseja ir no histórico de confirmações. Você não precisa ser exato, pois você poderá escolher commits específicos para squash quando executar o comando interactive rebase. Por exemplo, se você quiser esmagar confirmações dentro das últimas cinco confirmações, execute:
```
git rebase -i HEAD~5
```
O Git abrirá um editor que lista as últimas cinco confirmações, começando pelas 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 fundir um commit com o que está acima, mude pick para squash. Por exemplo, para combinar as duas confirmações superiores e também as duas confirmações inferiores, modifique a lista de confirmações 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. 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ções, condense as mensagens de confirmação em 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
```
Embora a confirmação Fix fiber optic transmitter test não tenha sido esmagada, ela tem uma nova ID de confirmação porque agora se vincula a uma confirmação antecessora diferente.

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

Observação

Os utilizadores do Azure DevOps podem realizar um squash merge para condensar o histórico de commits de uma ramificação de tópico durante um pull request.

Próximos passos

Copiar alterações utilizando cherry-pick

Feedback

Esta página foi útil?

Last updated on 2025-12-17