Este é o primeiro de uma série de artigos sobre coisas legais e perigosas que podemos fazer com Git.

Rebase versus Merge

O Rebase é um comando que tem uma reputação ruim. Com bastante frequência, ouço de outras pessoas que uma das primeiras lições que tiveram ao aprender Git, é que o Rebase é um comando proibido por ser muito perigoso. Mas o que muita gente não sabe é que o Rebase, quando dominado, pode ajudar muito a vida do desenvolvedor ou do DevOps.

Merge

Uma das coisas mais importantes sobre o Rebase, é que ele resolve o mesmo problema do Merge: ambos integram mudanças de um branch para outro, só que de maneira diferente.

Imagine que você comece trabalhando em uma nova feature de um branch e então outro membro do time atualiza o branch master. O que temos como resultado é um fork do histórico que é bem familiar para qualquer um que já usou o Git:

Agora, digamos que os novos commits no branch master são importantes para a feature na qual você está trabalhando. Para adicionar os novos commits no branch feature, você tem duas opções: Merge ou Rebase.

Fazendo o Merge

É a opção mais fácil. Podemos fazer o Merge do master em nosso branch com o comando:

git checkout feature
git merge master

O resultado é a criação de um commit do próprio Merge, unindo os históricos dos dois branches. Então temos agora uma estrutura parecida com esta:

O merge é interessante porque é uma operação não destrutiva. Os commits dos branches existentes não são alterados e isso evita alguns riscos do Rebase.

Por outro lado, também significa que o branch feature terá um um commit irrelevante todas as vezes que você precisar incorporar mudanças. Se o branch principal tem muita atividade, isso vai poluir bastante o branch no qual está trabalhando e isso gera impacto direto aos outros desenvolvedores, que não vão conseguir entender o histórico do projeto.

Rebase

Então, como alternativa ao Merge, você pode fazer o Rebase do branch feature no branch master, utilizando os comandos:

git checkout feature
git rebase master

Basicamente, o que o rebase faz é reproduzir, commit por commit, as ações que você desejar. No nosso caso, reproduzindo os novos commits de master no branch feature.

E se você não se sente confortável com o Git Rebase, você pode treinar o Rebase em um branch temporário. Assim, se você fizer besteira, você pode tentar de novo fazendo um checkout do branch original:

git checkout feature
git checkout -b temporary-branch
git rebase -i master
# [Clean up the history]
git checkout master
git merge temporary-branch

Depois do Rebase, o nosso histórico fica assim:

 

A Regra Áurea do Rebase

Agora que já entendemos basicamente o que é o rebase, precisamos falar da Regra Áurea:

“Nunca faça um rebase enquanto você está trabalhando em um branch público”.

O problema é que isso precisa ser combinado com as outras pessoas envolvidas no repositório. Lembre-se, com o rebase nós estamos reescrevendo a história, então é como uma conspiração: todos precisam estar dentro do esquema para tudo dar certo. E quanto mais pessoas envolvidas, mais difícil fica.

Por enquanto é isso, pessoal! Na parte 2 desta série vou falar um pouco mais de outras coisas que podemos fazer com o Git Rebase, usando o modo interativo.

Algumas referências, caso queira estudar mais:

• Merging vs. Rebasing – Atlassian;
• The Golden Rule Of Rebasing;
• The Advanced Git Guide: Git Stash, Reset, Rebase, and More;
• Git Rebase Interactive :: A Practical Example;
• David Baumgold – Advanced Git – PyCon 2015.

Até a próxima!

***

Este artigo foi publicado originalmente em: https://www.concrete.com.br/2017/09/04/git-para-corajosos-rebase-parte-1/