Série Git na Prática: Entendendo o rebase

Olá, pessoal! No artigo de hoje vamos entender o rebase que temos no git – acho que esta é umas das mais importantes features dele.

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 no branch com o código de dois dias atrás. Podemos ter problemas e sérios conflitos na hora do merge. E se for para ter conflito, que seja pequeno e de imediato.

Considerando o cenário dos artigos anteriores, onde temos o branch development, vamos supor que ficamos trabalhando no 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 ele esteja igual ao 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 um branch temporário e pega os commits do master e coloca no branch; depois ele pega os commit que ele mesmo colocou no branch temporário e coloca de volta no 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 que desenhei:

E depois que terminamos de trabalhar com o branch, podemos fazer um merge. Assim, teremos o master atualizado, conforme podemos ver na última imagem (de cima para baixo).

Esse é o rebase. Simples, não?

Abraços.