Diferença entre Git ReBase e Merge
Neste artigo, discutiremos duas dessas ferramentas, Rebase e Merge, e suas diferenças. O GIT é um dos controladores de versão distribuída DVCS mais comumente usados entre os programadores, devido à sua natureza dinâmica e à vasta disponibilidade de ferramentas para lidar com as versões. Existem duas maneiras pelas quais podemos enviar nossas alterações de um ramo para outro. Uma é usando Rebase e a outra é Merge, que é bastante popular. Abaixo, aprendemos a melhor comparação entre Git ReBase e Merge.
Comparação cara a cara entre Git ReBase vs Merge (Infographics)
Abaixo estão as 5 principais comparações entre Git ReBase e Merge:
Principais diferenças entre Git ReBase e Merge
Vamos discutir a principal diferença entre Git ReBase e Merge:
1. Git Rebase
O Git Rebase começa seu trabalho a partir de um commit comum entre os dois ramos. Mestre e recurso, a partir daqui, ele compara os dois e captura o instantâneo da diferença que é feita em um dos ramos e depois o adiciona a outros. Vejamos isso com as capturas de tela abaixo.
Vamos imaginar que temos uma ramificação principal e a confirmação mais recente de m2, como mostrado na captura de tela acima. A partir desta confirmação, criamos um ramo de recurso e fizemos algumas modificações e confirmamos com a mensagem f1. Agora, vamos considerar que alguém mesclou seu trabalho ao mestre e agora o último commit do mestre é m3, não m2, como mostrado abaixo.
E também continuamos trabalhando no ramo de recursos para adicionar seu último commit a f2, como mostrado abaixo.
Como visto acima, no screengrab, dominamos o commit m3 mais recente e temos um recurso que não está atualizado com o master, pois ele foi criado a partir do snapshot de commit m2 que possui o commit mais recente como f3. Agora, a combinação desses esforços com o mestre para gerar é mostrada abaixo.
Agora precisamos integrar as alterações acima, que podem ser feitas de duas maneiras, uma com mesclagem e outra com rebase. Aqui veremos como integrar com o rebase.
$ git checkout feature
Switched to a new branch 'feature'
$ git rebase master
A partir do comando rebase acima, tentaremos procurar uma confirmação comum do mestre e do recurso e, neste caso, é m2. E, como precisamos refazer o master, ele procurará adições feitas com o master e terá o snapshot m3 e o recurso de rebase de m2 para m3. Então agora temos um recurso com m3 (no lugar de m2), f1, f2 confirma. Agora posso me candidatar a refazer o recurso para atualizar a ramificação principal com as alterações do recurso. Uma coisa a lembrar é que qualquer alteração no mestre deve ser auditada. Aqui estou apenas mostrando, por exemplo, propósito.
$ git checkout master
Switched to a new branch 'master'
$ git rebase feature
Agora, aplicaremos o ramo de recurso de confirmação mais recente, que é f2, para o mestre, e o último instantâneo de confirmação do mestre será f2. Você pode listar as confirmações usando o comando git log, mas precisamos verificar primeiro em qual ramificação precisamos ver o log como abaixo.
$ git checkout feature
Switched to a new branch 'feature'
$ git log
Agora, com o rebase, integramos as atualizações de um recurso a ser dominado. Vamos tentar conseguir isso por fusão.
2. Git Merge
Também usaremos a captura de tela acima para a referência aqui, e podemos obter o mesmo que conseguimos com rebase e mesclagem.
O Git merge confirma o último commit que tivemos no ramo de recursos e aqui o caso é com o commit de f2, que reúne todas as alterações e o mescla com o último commit que temos no ramo principal, m3 aqui. Isso parece complicado, mas pode ser facilmente executado pelo comando mesclar. Podemos fazer uma mesclagem direta ou mescla de squash e a diferença em ambos.
$ git checkout master
Switched to a new branch 'master'
$ git merge feature
O comando acima terá todos os commits do recurso e adicionará também o log do mestre. Para evitar que possamos usar squash para que, no log do mestre, após m3 apenas um commit seja atualizado
$ git checkout master
Switched to a new branch 'master'
$ git merge –squash feature
deve-se ter cuidado ao usar o git rebase e tentar evitá-lo. A regra de ouro é evitá-lo usando agências públicas.
Basta olhar para o cenário acima. Isso pode acontecer quando você tenta rebase o master em cima do seu ramo de recursos e nosso ramo principal é público, agora o ramo principal é atualizado, mas todo mundo está trabalhando em uma versão mais antiga do mestre. Como o rebaseamento resultará em novos commit, o git pode pensar que a história do ramo principal divergiu de todos os outros. A única maneira de resolver isso será sincronizar o mestre, mesclando-o novamente e ter um conjunto resultante de confirmações que serão confusas.
Tabela de comparação do Git ReBase vs Merge
A tabela abaixo resume as comparações entre Git ReBase e Merge:
| Base de comparação entre Rebase e Merge | Rebase | Mesclar |
| Confirma | Ele altera e reescreve o histórico, criando um novo commit para cada commit na ramificação de origem. | Ele incorpora todas as alterações na origem, mas mantém a ancestralidade de cada histórico de consolidação, mas incorpora todas as alterações na origem, mas mantém a ancestralidade de cada histórico de consolidação. |
| Seleção | Aqui, primeiro verificamos a ramificação que precisa ser reestruturada e, em seguida, selecionamos o comando rebase para adicionar atualizações a outras pessoas. | Aqui, verifique primeiro a ramificação que precisa ser mesclada primeiro. Em seguida, execute a operação de mesclagem e a confirmação mais recente da fonte será mesclado com a confirmação mais recente do mestre. |
| Tratamento de Conflitos | Como o histórico de commit será reescrito para entender o conflito, será difícil alguns casos. | O conflito de mesclagem pode ser facilmente tratado, entendendo o erro que foi executado durante a mesclagem. |
| regra de ouro | Deve usar nos ramos públicos, pois o histórico de confirmação pode causar confusão. | Não há muito mal ao executar ramificações públicas. |
| Acessibilidade | As confirmações que já foram alcançáveis não serão mais alcançadas após a nova reformulação, pois o histórico de alterações foi alterado. | As confirmações permanecerão acessíveis dos ramos de origem. |
Conclusão
Mesclar e Rebase são duas ferramentas poderosas do Git e ambas são usadas para incorporar as alterações nos desvios, mas devemos ter um pouco de cuidado com o rebase, pois ele reescreverá o histórico de confirmações e usá-las em desvios públicos pode dificultar o trabalho de outros causando confusão. Considerando que você pode usar a opção de mesclagem, pois suas confirmações são acessíveis a partir da ramificação de origem e pode facilmente resolver conflitos de mesclagem, se tivermos um entendimento adequado.
Artigos recomendados
Este é um guia para a principal diferença entre Git ReBase e Merge. Aqui também discutimos as principais diferenças entre Git ReBase e Merge com infográficos e tabela de comparação. Você também pode consultar os seguintes artigos para saber mais -
- Git Fetch vs Git Pull - Principais Diferenças
- Abstração vs Encapsulamento | Top 6 Comparação
- Arquitetura HBase com vantagens
- Perguntas da entrevista do GIT | 11 principais
- Sistema de Controle de Versão GIT
- Git Push
- Encapsulamento em JavaScript
- Guia completo do comando remoto Git
- Três estágios do ciclo de vida do Git com o fluxo de trabalho
- Como usar o GIT Cherry-pick com o Exemplo?