Utilizando Git Rebase de maneira mais fácil e intuitiva (João Vitor Magalhães Leite e Pedro Zamecki Andrade)
O rebase
é uma das duas maneiras mais comuns de integrar branches quando se utiliza Git (a outra sendo o merge
). Branches são um dos aspectos fundamentais da utilização de ferramentas de versionamento, como o Git. Dessa maneira, saber como lidar com a mesclagem das branches é importante para um bom aproveitamento do trabalho realizado, buscando garantir os resultados esperados por parte dos usuários.
Diferenças entre Rebase e Merge
[editar | editar código-fonte]O merge
pode ser confundido com o rebase
por ser, em muitos, parecido em uso com o mesmo, porém simplificando suas características podemos compilar as carecterísticas de ambos:
![](http://upload.wikimedia.org/wikipedia/commons/thumb/0/01/MergeDemonstra%C3%A7%C3%A3o.webp/313px-MergeDemonstra%C3%A7%C3%A3o.webp.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/7/78/RebaseDemonstra%C3%A7%C3%A3o.webp/313px-RebaseDemonstra%C3%A7%C3%A3o.webp.png)
Merge | Combina históricos | Históricos com bifurcações | Não altera commits, existentes somente cria | Conflitos resolvidos de uma única vez | Ideal para preservar históricos completos |
Rebase | Move os commits | Cria um histórico linear | Pode alterar commits existentes | Conflitos devem ser resolvidos por commit | Ideal para manter históricos limpos e lineares |
O rebase
não se limita somente a mudar de base, em seu modo iterativo ele tem ainda mais funções, como por exemplo omitir commits julgados como desnecessários, como por exemplo resolução de pequenos comentários em pull requests, como mudança em nome de variáveis, alterações que não afetam o funcionamento do código de nenhuma maneira.
Vale a pena relembrar que o comando git rebase
não se une à sua base, ou seja, de qualquer forma o comando não substitui o git merge
, mas seu uso fica bastante trivial e o resultado, dependendo da situação, pode ser preferível.
Vantagens do Rebase
[editar | editar código-fonte]Fazer o rebase
pode ser muito útil em alguns casos, a sua leitura linear do histórico pode ajudar bastante ao se tentar entender, é bem mais intuitivo ter que ver uma linha reta do que uma bifurcação no gráfico, para se procurar erros e analisar features pode ser bem útil, já que até a sua navegação fica mais simplificada, o uso dos comandos git log
e o git bisect
fica mais fácil de se ler e entender.
Além disso, permite com que as features trabalhadas se incorporem de maneira contínua, ou seja, ao se atualizar a branch base, se usa o git rebase
para que a branch no qual se baseia-se fique mais atualizada o que evita possíveis conflitos maiores no futuro.
Ao se dividir os conflitos em partes com o comando também pode ficar bem mais fácil de se entender e diminuir os conflitos, o que ajuda bastante no desenvolvimento contínuo com colaboradores.
Por último, os pull requests
ficam bem mais limpos e fáceis de se lerem, uma vez que o histórico é linear e a leitura é facilitada, fazendo com que as mudanças sejam mais focadas na feature em si do que nas mudanças gerais dos commits.
Os perigos do Rebase
[editar | editar código-fonte]É importante notar que, como qualquer outra ferramenta, o rebase
pode mais atrapalhar do que ajudar no caso de ser mal utilizado.
Se não usado com cuidado, o rebase pode levar a perda de commits, no caso de se omitir commits importantes. Também no caso do histórico ser reescrito temos que caso outra pessoa esteja desenvolvendo e tenha um histórico antigo em sua máquina, caso não atualize o mais rápido o possível sua branch, pode causar uma grande confusão e grande quantidade de conflitos, fazendo muito trabalho ser perdido.
Conflitos frequentes podem ser um dos maiores desafios do rebase
uma vez que trabalhando numa branch no qual a base é atualizada constantemente podem gerar muitos commits e em muitas vezes podem gerar vários erros de conflitos ao tentar fazer o rebase, as vezes na mesma parte do código, o que pode mais confundir do que ajudar, além de gastar muito tempo e ser muito frustrante.
Além de tudo, o rebase
é uma ferramenta poderosa que permite fazer várias coisas, por exemplo, omitir outros commits relacionados, apesar de muito útil em pequenos casos, não é nem um pouco recomendado em grandes mudanças no código, isso somado a um git push --force
pode significar a perda de muitos dados.
Como facilitar o Rebase
[editar | editar código-fonte]Finalmente, aqui falaremos de como facilitar o rebase
, para isso é importante manter algumas boas práticas na programação no geral:
- Uso do rebase iterativo: utilize
git rebase -i
para controlar e revisar o processo do rebase, é isso o que permite editar, reordenar e combinar commits, tornando o histórico mais claro e simples, e isso em futuros casos facilitam outras iterações do comando além de facilitar o merge (que não pode ser substituído) na finalização da feature desejada. Em algumas IDEs é possível ter uma informação mais visual de como fazer isso, o que ajuda muito na hora de simplificar orebase
. - Uso constante de rebases pequenos: ao se fazer o comando várias vezes o processo fica cada vez mais fácil de ser executado, com alguns possíveis conflitos no código, mas bem menores do que somente um merge no final da vida da branch, o que facilita bastante a solução da maior parte dos problemas do rebase
- Uso de ferramentas de solução de conflitos: hoje em dia existem várias ferramentas dessa sendo as mais comuns as extensões de IDEs usadas, e também ferramentas como `meld` e `kdiff3`. Como os conflitos são inevitáveis o uso dessas ferramentas são basicamente necessárias para fazer um rebase ou até mesmo um merge.
- Testar após fazer o rebase e antes de dar o `git push`: é importante sempre verificar se tudo deu certo antes de fazer o push, o rebase tecnicamente muda sim a funcionalidade do código já que várias linhas de código podem ter sido alteradas sem mesmo saber, por isso, os testes são praticamente essenciais antes de fazer o
git push
. - Usar a flag `--force-with-lease`: basicamente é comum usar o comando `
git push --force
` após terminar de fazer um rebase bem sucedido, porém o uso da flag `--force-with-lease` garante que não houve mudanças na branch remota antes de fazer o push, o que é muito bom quando não se quer sobrescrever o código dos colaboradores.