Olá Pessoal,
No post de hoje vamos entender o rebase que temos no git. Acho umas das mais importantes features do git.
Lets go…
Starting …
O rebase é algo tão comum quanto tomar café todos os dias. Na prática, precisamos dele quando estamos trabalhando na branch e sabemos que o repositório master foi atualizado por outros desenvolvedores e precisamos ter nosso branch atualizado, concorda? Não é nada legal ficarmos trabalhando na branch com o código de 2 dias atrás. Podemos ter problemas e sérios conflitos aqui na hora do merge, o melhor é que se for ter conflito que seja pequeno e de imediato.
In practice
Considerando o cenário dos posts anteriores onde temos a branch development, vamos supor que ficamos trabalhando na branch por alguns dias e a master sofreu alteração, alguém adicionou um novo arquivo lá e fez o commit.
E agora precisamos trazer esse novo arquivo para o branch, assim vamos garantir que nossa branch está igual à master.
Para isso:
1 Vamos na branch git checkout development
2 Dizer para realizar um rebase da branch master
git rebase master
E o que acontece aqui?
Simples, o git se encarrega de colocar os commit que foram feitos na branch em uma branch temporária e pega os commits da master e coloca na branch, depois ele pega os commit que ele mesmo colocou na branch temporária e coloca de volta na branch development. Aqui ele valida commit por commit, ou seja, é possível ter conflito e teremos que resolver manualmente. Veja como ficou o branch com o novo arquivo que tínhamos apenas na master:
A seguir o ciclo:
E depois que terminamos de trabalhar com a branch podemos fazer um merge, como vimos nesse post. E termos a master atualizada, conforme podemos ver na última imagem (de cima para baixo).
Esse é o rebase. Simples, não?
See ya !! Abraços.
O desenho não ficou bom para o entendimento real do que o rebase faz. Também faltou explicar as diferenças entre merge e rebase, e os impactos que um rebase pode causar dependendo do cenário do momento.