[Git] Realizando Merges com o Comando Rebase

Anderson Gomes
Jul 24, 2017 · 3 min read

Nos post anteriores, vimos que é possível fazer merge de dois branches com o comando merge e que, na história de versionamento do repositório, se se tratarem de dois branches divergentes, surgem ramificações que posteriormente se unem ao branch principal. Em projetos mais complexos, a quantidade de branches e, consequentemente, a quantidade de ramificações na história do repositório, pode ser elevada e o processo de merge desses branches pode ser tornar trabalhoso.

Quando se trata de um repositório que queremos colaborar mas não temos permissão de alterar o master, muitas vezes precisamos seguir algumas regras que facilite o trabalho do mantedor do projeto. Uma das regras mais comuns é que nossas colaborações sigam uma história linear para que sejam passíveis de fast-forward, ou seja, que não gerem conflitos ao serem utilizadas em um merge com o branch principal.

Nessa situação, ao utilizarmos a estratégia de merge que conhecemos, só temos uma alternativa: criar um branch a partir do commit mais recente do master, concluir as alterações e torcer para que nenhum novo commit tenha sido realizado no branch master do repositório remoto, caso contrário, quando o branch for enviado para o servidor, ele surgirá como uma ramificação de um commit anterior e correrá o risco de introduzir conflitos se for unido ao branch master em um merge, um trabalho que o mantedor do repositório não quer.

Por isso devemos utilizar uma solução que, independente de quantos commits foram realizados no master enquanto estávamos trabalhando no nosso branch, nos permita alterar o histórico de commits baseando todas as nossas alterações no commit mais recente do branch principal. Para isso recorremos ao comando rebase.

Suponha que clonamos um repositório remoto com três commits no branch master, criamos um branch chamado bugfix localmente e executamos dois commits nesse branch:

Depois de concluídas as alterações, executamos um fetch e descobrimos que mais dois commits foram realizados no master do servidor remoto.

$ git fetch origin

Como nosso branch está divergindo da história linear do master, vamos utilizar o comando rebase para que as nossas alterações se baseiem no último commit do master.

$ git rebase master

Veja que os dois commits que criamos no branch bugfix foram removidos e dois novos foram criados após o último commit do master. Se verificarmos o histórico de commits com o comando log, veremos que todos os dados dos commits removidos(como autor, data e mensagem) foram copiados para os novos. Caso ocorram conflitos em algum arquivo do repositório, depois de resolvê-lo temos que adicioná-los à área de stage com o comando add e executar novamente o comando rebase com a opão continue. Por exemplo:

$ git rebase master
CONFLITO(conteúdo):conflito de mesclagem em file.txt
// resolvendo conflitos no arquivo file.txt...
$ git add file.txt
$ git rebase --continue

Agora podemos subir nosso branch para o servidor como se tivéssemos implementado as alterações nos baseando no commit mais recente do repositório, possibilitando ao mantendor do projeto executar um merge sem problemas de conflitos.

$ git push -u origin bugfix
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade