Differenza tra Git ReBase vs Merge
In questo articolo, discuteremo di due di questi strumenti Rebase e Merge e la loro differenza. GIT è uno dei controller di versione distribuita DVCS più comunemente usati tra i programmatori per la sua natura dinamica e la vasta disponibilità di strumenti per gestire le versioni. Esistono due modi con cui possiamo inviare le nostre modifiche da un ramo all'altro. Uno è utilizzando Rebase e l'altro è Merge, che è abbastanza popolare. Di seguito apprendiamo il confronto tra Top Git ReBase e Merge.
Confronto testa a testa tra Git ReBase vs Merge (Infographics)
Di seguito sono riportati i primi 5 confronti tra Git ReBase vs Merge:
Differenze chiave tra Git ReBase vs Merge
Discutiamo la differenza chiave tra Git ReBase vs Merge:
1. Git Rebase
Git Rebase inizia il suo lavoro da un commit comune tra i due rami. Master e funzionalità, da qui confronta entrambi e acquisisce l'istantanea della differenza che viene eseguita in uno dei rami e quindi lo aggiunge ad altri. Vediamo questo con le schermate seguenti.
Immaginiamo di avere un ramo principale e l'ultimo commesso ad esso m2, come mostrato nella schermata sopra. Da questo commit, creiamo un ramo di funzionalità e abbiamo apportato alcune modifiche e il commit con il messaggio f1. Consideriamo ora che qualcuno ha unito il suo lavoro al master e ora l'ultimo commit del master è m3, non m2 come mostrato di seguito.
E continuiamo anche a lavorare sul ramo delle caratteristiche per aggiungere il suo ultimo commit ad essere f2 come mostrato di seguito.
Come visto da sopra screengrab, abbiamo imparato l'ultimo commit m3 e abbiamo una funzione che non è aggiornata con il master poiché è stata creata dall'istantanea del commit di m2 che ha l'ultimo commit come f3. Ora, combinare questi sforzi con il master per generare è mostrato di seguito.
Ora dobbiamo integrare le modifiche di cui sopra che possono essere fatte in due modi: una con unione e l'altra con rebase. Qui vedremo come integrarsi con rebase.
$ git checkout feature
Switched to a new branch 'feature'
$ git rebase master
Dal comando rebase sopra proveremo a cercare un commit comune sia da master che da feature e in questo caso è m2. E poi, dal momento che dobbiamo rebase master, cercherà le aggiunte che sono state fatte con master e scatta la funzione m3 e rebase da m2 a m3. Quindi ora abbiamo una funzione con commit di m3 (al posto di m2), f1, f2. Ora posso fare domanda per riformulare la funzione per aggiornare il ramo master con le modifiche della funzione. Una cosa da ricordare è che qualsiasi modifica a master deve essere verificata. Qui sto solo mostrando scopo per esempio.
$ git checkout master
Switched to a new branch 'master'
$ git rebase feature
Ora in questo, applicheremo il ramo della funzione di commit più recente che è f2 per il master e l'ultima istantanea del commit del master sarà f2. Puoi elencare i commit usando il comando git log ma dobbiamo prima controllare su quale ramo dobbiamo vedere il log come di seguito.
$ git checkout feature
Switched to a new branch 'feature'
$ git log
Ora con rebase, abbiamo integrato gli aggiornamenti di una funzionalità da padroneggiare. Proviamo a raggiungere questo obiettivo unendo.
2. Git Merge
Useremo lo screenshot sopra per il riferimento anche qui, e possiamo ottenere lo stesso risultato ottenuto anche con rebase e merge.
Git merge commette l'ultimo commit che abbiamo avuto nel ramo delle caratteristiche e qui il caso è con il commit f2, che raccoglie tutte le modifiche e le unisce all'ultimo commit che abbiamo nel ramo principale, m3 qui. Sembra complicato ma può essere facilmente eseguito dal comando unisci. Possiamo fare una fusione diretta o una fusione squash e la differenza in entrambi.
$ git checkout master
Switched to a new branch 'master'
$ git merge feature
Il comando precedente prenderà tutti i commit della funzione e aggiungerà anche il registro del master. Per evitare che possiamo usare squash in modo che nel registro del master dopo m3 ci sarà solo un commit e questo è di aggiornamento
$ git checkout master
Switched to a new branch 'master'
$ git merge –squash feature
bisogna stare attenti mentre si usa git rebase e cercare di evitarlo. La regola d'oro è di evitarlo usando filiali pubbliche.
Guarda lo scenario sopra. Questo può accadere quando provi a riordinare il master in cima al ramo della tua funzione e il nostro ramo principale è pubblico, ora il ramo principale viene aggiornato ma tutti gli altri stanno lavorando su una versione precedente di master. Dal momento che il rifacimento si tradurrà in nuovi impegni, git può pensare che la storia del ramo principale sia divergente da tutti gli altri. L'unico modo per risolverlo sarà sincronizzare entrambi i master unendoli nuovamente insieme e avere una serie risultante di commit che sarà fonte di confusione.
Tabella comparativa di Git ReBase vs Merge
La tabella seguente riassume i confronti tra Git ReBase vs Merge:
| Base di confronto tra Rebase vs Merge | rebase | Merge |
| commit | Cambia e riscrive la cronologia creando un nuovo commit per ciascun commit nel ramo di origine. | Incorpora tutte le modifiche alla fonte ma mantiene la genealogia di ogni cronologia di commit incorpora tutte le modifiche alla fonte ma mantiene la genealogia di ogni cronologia di commit. |
| Selezione | Qui controlliamo prima il ramo che deve essere riformulato, quindi selezioniamo il comando rebase per aggiungere aggiornamenti ad altri. | Qui prima controlla il ramo che deve essere unito per primo. Quindi eseguire l'operazione di unione e l'ultimo commit dell'origine verrà unito all'ultimo commit del master. |
| Gestione dei conflitti | Dal momento che la cronologia degli commit verrà riscritta per capire che il conflitto sarà difficile alcuni casi. | Unisci conflitto può essere facilmente gestito comprendendo l'errore che è stato compiuto durante l'unione. |
| regola d'oro | Dovrebbe usare sulle filiali pubbliche poiché commettere cronologia può causare confusione. | Nessun danno durante l'esecuzione di filiali pubbliche. |
| raggiungibilità | I commit che una volta erano raggiungibili non saranno più raggiungibili dopo il rebase poiché la cronologia dei commit è cambiata. | Gli impegni rimarranno raggiungibili dai rami di origine. |
Conclusione
Unisci e Rebase sono un paio di due potenti strumenti di Git ed entrambi sono usati per incorporare le modifiche ai rami ma dobbiamo stare un po 'attenti con rebase poiché riscriverà la storia dei commit e usarli su rami pubblici può ostacolare il lavoro di altri che causano loro confusione. Considerando che è possibile utilizzare l'opzione di unione in quanto i suoi commit sono raggiungibili dal ramo di origine e possono facilmente risolvere i conflitti di unione se abbiamo una comprensione adeguata.
Articoli consigliati
Questa è una guida alla differenza principale tra Git ReBase vs Merge. Qui discutiamo anche le differenze chiave tra Git ReBase e Merge con infografica e tabella comparativa. Puoi anche dare un'occhiata ai seguenti articoli per saperne di più -
- Git Fetch vs Git Pull: differenze principali
- Astrazione vs incapsulamento | Top 6 Confronto
- Architettura HBase con vantaggi
- Domande di intervista GIT | Primi 11
- Sistema di controllo versione GIT
- Git Push
- Incapsulamento in JavaScript
- Guida completa al comando remoto Git
- Tre fasi del ciclo di vita di Git con il flusso di lavoro
- Come usare GIT Cherry-pick con Esempio?