Git rebase: tutto quello che c'è da sapere

Il comando Git rebase sposta un ramo in una nuova posizione all'inizio di un altro ramo. A differenza del comando Git merge, rebase comporta la riscrittura della cronologia del progetto. È un ottimo strumento, ma non rebase commit su cui altri sviluppatori hanno basato il lavoro.

Il comando Git rebase combina due rami di codice sorgente in uno solo. Anche il comando Git merge fa questo. Spieghiamo cosa fa rebase, come viene utilizzato e quando utilizzare invece merge.

Sommario

L'esplosione di Git
Cos'è Git merge?
Cos'è Git rebase?
Come eseguire il rebase su un altro ramo
Git Rebase vs. Merge: quale dovresti usare ?
Rebase o non Rebase?

The Git Explosion

Frustrato con altri sistemi di controllo della versione e i loro lenti aggiornamenti e commit, Linus Torvalds, famoso per il kernel Linux, ha messo da parte un mese nel 2005 per scrivere il suo. Lo ha chiamato Git.

Siti come GitHub, GitLab e BitBucket hanno promosso e beneficiato simbioticamente di Git. Oggi Git è utilizzato a livello globale, con un enorme 98% di 71mila intervistati in un sondaggio del 2022 che utilizza Git come sistema di controllo della versione.

Una delle principali decisioni di progettazione di Git è stata la velocità. In particolare, lavorare con le filiali doveva essere il più veloce possibile. I rami sono una parte fondamentale dei sistemi di controllo della versione. Un repository di progetto avrà un ramo principale o master. Qui è dove si trova la base di codice del progetto. Lo sviluppo, come le nuove funzionalità, avviene in rami secondari separati. Ciò impedisce al lavoro svolto nei rami di incasinare il ramo principale e consente lo sviluppo simultaneo in diverse parti della base di codice.

RELATEDCome scegliere il flusso di lavoro Git e il modello di branching adatto al tuo team

Man mano che gli sviluppi nei rami secondari vengono completati, le modifiche vengono trasferite al ramo principale unendo il ramo di sviluppo nel ramo principale. In altre versioni i sistemi di controllo che lavorano con i rami erano difficili e computazionalmente costosi. Lavorare con i rami in Git è molto veloce e molto leggero. Quello che una volta era un esercizio noioso e spesso evitato in altri sistemi, è diventato banale in Git.

Il comando Git rebase è un altro modo per trasferire le modifiche da un ramo all'altro. I comandi merge e rebase hanno obiettivi simili, ma raggiungono i loro scopi in modi diversi e producono risultati leggermente diversi.

Che cos'è Git merge?

Allora a cosa serve il comando Git merge? Supponiamo che tu abbia creato un ramo chiamato dev-branch per lavorare su una nuova funzionalità.

Prendi alcuni impegni e prova la tua nuova funzione. Funziona tutto bene. Ora vuoi inviare la tua nuova funzione al ramo principale. Devi essere nel ramo principale per unirne un altro.

Possiamo assicurarci di essere nel ramo principale controllandolo esplicitamente prima di eseguire l'unione.

git checkout master

Ora possiamo dire a Git di unire il ramo dev-nel ramo corrente, che è il ramo principale.

git merge dev-branch

La nostra unione è completata per noi. Se effettui il checkout del ramo principale e lo compili, conterrà la funzionalità appena sviluppata. Ciò che Git ha effettivamente eseguito è un'unione a tre vie. confronta i commit più recenti nei rami master e dev-branch e il commit nel ramo master immediatamente prima della creazione del ramo dev. Quindi esegue un commit sul ramo principale.

Le unioni sono considerate non distruttive perché non eliminano nulla e non modificano la cronologia di Git. Il ramo dev esiste ancora e nessuno dei commit precedenti viene modificato. Viene creato un nuovo commit che acquisisce i risultati dell'unione a tre vie.

Dopo l'unione, il nostro repository Git appare come una timeline con una linea alternativa che si dirama e poi ritorna alla timeline principale.

Il ramo dev-branch è stato incorporato nel ramo master.< /p>

Se hai molti rami in un progetto, la cronologia del progetto può diventare confusa. Questo è spesso il caso se un progetto ha molti contributori. Poiché lo sforzo di sviluppo si suddivide in molti percorsi diversi, la cronologia dello sviluppo non è lineare. Districare la cronologia dei commit diventa ancora più difficile se i rami hanno i propri rami.

RELATEDCome funzionano i rami Git?

Tieni presente che se hai modifiche non salvate nel ramo principale, dovrai fare qualcosa con queste modifiche prima di poter unire qualsiasi cosa ad esso. Potresti creare un nuovo ramo e confermare le modifiche lì, quindi eseguire l'unione. Dovresti quindi unire il tuo ramo temporaneo nel ramo principale.

Funziona, ma Git ha un comando che ottiene la stessa cosa, senza dover creare nuovi rami. Il comando stash memorizza le modifiche non salvate per te e ti consente di richiamarle con stash pop .

Le useresti in questo modo:

stash git merge dev-branch stash pop < p>Il risultato finale è un ramo unito, con le modifiche non salvate ripristinate.

Cos'è Git rebase?

Il comando Git rebase raggiunge i suoi obiettivi in un modo completamente diverso. Prende tutti i commit dal ramo su cui stai per eseguire il rebase e li riproduce alla fine del ramo su cui stai effettuando il rebase.

Prendendo il nostro esempio precedente, prima di eseguire qualsiasi azione il nostro repository Git si presenta così. Abbiamo un ramo chiamato dev-branch e vogliamo spostare le modifiche al ramo principale.

Dopo il rebase , sembra un'unica linea temporale di modifiche completamente lineare.

Il ramo dev è stato rimosso e i commit nel ramo dev sono stati aggiunti al ramo master. Il risultato finale è lo stesso che se i commit nel ramo dev fossero stati effettivamente impegnati direttamente nel ramo master in primo luogo. I commit non sono semplicemente aggiunti al ramo principale, vengono “riprodotti” e aggiunto fresco.

Questo è il motivo per cui il comando rebase è considerato distruttivo. Il ramo ribasato non esiste più come ramo separato e la cronologia Git del tuo progetto è stata riscritta. Non puoi determinare in un secondo momento quali commit sono stati originariamente fatti al ramo dev.

Tuttavia, ti lascia con una cronologia semplificata e lineare. Rispetto a un repository con dozzine o addirittura centinaia di diramazioni e unioni, leggendo il registro Git o utilizzando una GUI grafica git per guardare un grafico del repository, un repository ribasato è un gioco da ragazzi da capire.

Come eseguire il rebase su un altro ramo

Proviamo un esempio di git rebase. Abbiamo un progetto con un ramo chiamato new-feature. Ribaseremo quel ramo sul ramo principale in questo modo.

Per prima cosa, controlliamo che il ramo principale non abbia modifiche in sospeso.

git status

Verifichiamo la nuova funzionalità branch.

git checkout new-feature

Diciamo a Git di ribasare il ramo corrente sul ramo master.

git rebase master

Possiamo vedere che abbiamo ancora due rami.

p> ramo git

Torniamo al ramo principale

git checkout master

Uniamo il ramo new-feature nel ramo corrente, che nel nostro caso è il ramo master.

git merge new-feature

È interessante notare che abbiamo ancora due rami dopo il fusione finale.

La differenza è che ora l'head del ramo new-feature e l'head del branch master sono impostati per puntare allo stesso commit, e la cronologia di Git non mostra che prima c'era un ramo new-feature separato, a parte l'etichetta del ramo.

Git Rebase vs. Merge: quale dovresti usare?

Non è un caso di rebase contro unione. Sono entrambi comandi potenti e probabilmente li userai entrambi. Detto questo, ci sono casi d'uso in cui rebase non funziona molto bene. Gli errori di unpicking causati da errori che utilizzano merge sono spiacevoli, ma gli errori di unpicking causati da rebase sono infernali.

Se sei l'unico sviluppatore che utilizza un repository, ci sono meno possibilità che tu faccia qualcosa con rebase che sia disastroso. Potresti ancora ribasare nella direzione sbagliata, ad esempio, e ribasare il tuo ramo principale sul ramo della nuova funzionalità. Per riavere il tuo ramo principale, dovresti eseguire nuovamente il rebase, questa volta dal ramo della nuova funzionalità al ramo principale. Ciò ripristinerebbe il tuo ramo principale, anche se con una cronologia dall'aspetto strano.

Non utilizzare rebase su rami condivisi dove è probabile che altri funzionino. Le tue modifiche al tuo repository causeranno problemi a molte persone quando invierai il tuo codice ribasato al tuo repository remoto.

Se il tuo progetto ha più contributori, la cosa sicura da fare è utilizzare solo rebase sul tuo repository locale e non su rami pubblici. Allo stesso modo, se le richieste pull fanno parte delle revisioni del codice, non utilizzare rebase. O almeno, non utilizzare rebase dopo aver creato la richiesta pull. È probabile che altri sviluppatori guardino i tuoi commit, il che significa che tali modifiche si trovano su un ramo pubblico, anche se non sono sul ramo principale.

Il pericolo è che stai per ribasare i commit che sono già stati inviati a un repository remoto e altri sviluppatori potrebbero aver già basato il lavoro su quei commit. Il tuo rebase locale farà svanire quei commit esistenti. Se invii queste modifiche al repository non diventerai popolare.

RELATEDCome correggere, modificare o annullare i commit di Git (modificare la cronologia di Git)

Altri contributori dovranno passare attraverso un'unione disordinata per riportare il loro lavoro nel repository. Se poi riporti le loro modifiche al tuo repository locale, ti troverai di fronte all'estrazione di un pasticcio di modifiche duplicate.

To Rebase, o Non ribasare?

Rebase potrebbe essere fuorilegge nel tuo progetto. Potrebbero esserci obiezioni locali e culturali. Alcuni progetti o organizzazioni considerano il rebase come una forma di eresia e un atto di profanazione. Alcune persone credono che la storia di Git dovrebbe essere una registrazione inviolabile e permanente di ciò che è accaduto. Quindi, rebase potrebbe essere fuori discussione.

Ma, utilizzato localmente, su rami privati, rebase è uno strumento utile.

Spingi dopo aver ribasato e limitalo alle filiali in cui sei l'unico sviluppatore. O almeno, dove tutto lo sviluppo si è fermato e nessun altro ha basato nessun altro lavoro sui commit del tuo ramo.

Fallo ed eviterai qualsiasi problema.

RELAZIONATO: Come controllare e aggiornare la tua versione di Git

LEGGI SUCCESSIVO

› Quanto costa far funzionare uno spazzaneve elettrico?
› I requisiti telefonici USB-C dell'UE hanno ora una scadenza
› Hai appena lasciato la stanza senza mettere in pausa il film?
› Android 13 sta arrivando sulla tua TV
› Migliora l'audio della tua TV con la soundbar in saldo di Samsung
› Il nuovo monitor da gioco di LG ha il primo OLED a 240 Hz al mondo