Antes de comerçarmos a falar dos dois comandos, vamos entender quando eles devem ser usados.
Eles são usados quando o desenvolvedor cria um branch para o desenvolvimento de uma nova funcionalidade ou para correção de um bug em produção.
Existem muitos formas de trabalhar em equipe e a que eu adotei em meus projetos e sempre indico é o git-flow. Fluxo de versionamento que explico em outro post que se encontra nesse link.
O que é merge?
Basicamente o intuito do git -merge é juntar duas ou mais histórias de desenvolvimento. Essas histórias são chamadas de branch.
Então o merge incorpora as alterações para o branch atual.
Desde o momento em que seus históricos divergiram do branch atual.
Este comando é usado pelo git pull para incorporar mudanças de outro repositório, quando o remoto está atualizado e o local não e tem mudanças no mesmo arquivo ele faz merge automático ou da conflito. E também pode ser usado manualmente para mesclar as mudanças de um branch para outro.
Vamos falar do uso manual
Assumindo que existe um branch chamado de feature1 e o branch que você está é o master.
Então você vai executar o comando git merge feature1 pronto seu branch está atualizado.
Eita, deu conflito!
Caso ocorra o conflito e você queira desfazer. Você terá a necessidade de usar o comando git merge –abort Esse comando só pode ser executado depois do merge ter exibido conflito.
É possível resolver o conflito usando uma interface que você defini como merge tool. Basta usar o comando git mergetool esse comando vai abrir a interface gráfica definida.
Falando sobre o merge, usei a lei de pareto, para falar sobre o merge. Esses são os 20% necessários para você realizar os outros 80% das tarefas com merge.
O que é rebase?
É reaplicar commits em cima de outro branch.
O que acontece depois do comando?
Os commits que foram salvos anteriormente na área temporária são reaplicados ao branch atual, um por um, em ordem. Note que quaisquer commits no HEAD que introduzem as mesmas alterações textuais de um commit no HEAD. são omitidos (ou seja, um patch já aceito no upstream com uma mensagem de confirmação diferente ou timestamp será ignorado).
Vamos ao comando
Assumindo que você está no branch feature1 e você quer realizar o rebase na master, terá que executar o comando: git rebase master com esse comando você vai conseguir colocar todos os commits da branch feature1 na master sem gerar um commit de merge e na ordem cronológica correta.
Então qual dos dois devo usar?
Será sempre de acordo com as políticas do time. O que for definido deve ser seguido.
Devido a essa afirmação defendo o uso do git-flow, para facilitar a interação de um novo integrante. Diminuir problemas de comunicação, pois é um fluxo que tem bastante documentação na internet. Porém um fluxo não é ideal para todos os times, vai depender do que seu time quer implementar. Sempre devemos relevar as regras já existentes. Não existe uma bala de prata.
Uma estratégia de sucesso é desenhada de acordo com o projeto e com a capacidade do time. Já deixo nesse post uma promessa para um novo post sobre estratégias de branch.
Conclusão
Essa explicação foi para fornecer insights para vocês sobre o uso do Git merge e Git Rebase. É possível usar os dois ou apenas um, mas isso precisa ser definido para todo o time. Pois normalmente problemas com tecnologia ocorre por falta de comunicação ou do mal uso de uma forma que já está dando certo no mercado.
Se ainda estiver em dúvida de como usar o git, preparei um curso completo de git. Em 10 dias fazendo o curso você estará preparado para descobrir se é melhor usar git-flow, git merge, git rebase. O curso está na Udemy e por menos de 1,00 por mês você obtem esse conhecimento. Fundamental para o desenvolvedor que está participando de evolução tecnológica.
link para a Udemy