Il rebasing è il processo di spostamento o combinazione di una sequenza di commit in un nuovo commit di base. Il rebasing è molto utile e facilmente visualizzato nel contesto di un flusso di lavoro di ramificazione delle funzionalità. Il processo generale può essere visualizzato come segue:

Dal punto di vista del contenuto, rebasing sta cambiando la base del tuo ramo da un commit a un altro facendolo apparire come se avessi creato il tuo ramo da un commit diverso., Internamente, Git realizza questo creando nuovi commit e applicandoli alla base specificata. È molto importante capire che anche se il ramo sembra lo stesso, è composto da commit completamente nuovi.

Usage

La ragione principale per il rebasing è mantenere una cronologia lineare del progetto. Ad esempio, si consideri una situazione in cui il ramo principale è progredito da quando si è iniziato a lavorare su un ramo di funzionalità., Si desidera ottenere gli ultimi aggiornamenti al ramo master nel ramo feature, ma si desidera mantenere pulita la cronologia del ramo in modo che appaia come se si stesse lavorando all’ultimo ramo master. Ciò fornisce il vantaggio successivo di una fusione pulita del ramo di funzionalità nel ramo master. Perché vogliamo mantenere una “storia pulita”? I vantaggi di avere una cronologia pulita diventano tangibili quando si eseguono operazioni Git per indagare l’introduzione di una regressione. Uno scenario più reale sarebbe:

1. Un bug è identificato nel ramo master., Una funzionalità che funzionava correttamente è ora interrotta.
2. Uno sviluppatore esamina la storia del ramo master utilizzandogit log a causa della “storia pulita” lo sviluppatore è rapidamente in grado di ragionare sulla storia del progetto.
3. Lo sviluppatore non può identificare quando il bug è stato introdotto utilizzandogit logquindi lo sviluppatore esegue ungit bisect.
4. Poiché la cronologia git è pulita,git bisect ha un set raffinato di commit da confrontare quando si cerca la regressione., Lo sviluppatore trova rapidamente il commit che ha introdotto il bug ed è in grado di agire di conseguenza.

Scopri di più su git log e git bisect nelle loro singole pagine di utilizzo.

Hai due opzioni per integrare la tua funzionalità nel ramo master: unire direttamente o rebasing e quindi unire. La prima opzione si traduce in una fusione a 3 vie e un commit di unione, mentre la seconda si traduce in una fusione rapida e una cronologia perfettamente lineare. Il diagramma seguente mostra come il rebasing sul ramo master facilita un’unione rapida.,

Il rebasing è un modo comune per integrare le modifiche upstream nel repository locale. Tirando le modifiche upstream con Git merge si ottiene un commit di unione superfluo ogni volta che si desidera vedere come il progetto è progredito. D’altra parte, rebasing è come dire, “Voglio basare i miei cambiamenti su ciò che tutti hanno già fatto.”

Non rebase public history

Come abbiamo discusso in precedenza nella riscrittura della storia, non si dovrebbe mai rebase commit una volta che sono stati spinti a un repository pubblico., Il rebase sostituirebbe i vecchi commit con quelli nuovi e sembrerebbe che quella parte della cronologia del progetto sia improvvisamente scomparsa.

Git Rebase Standard vs Git Rebase Interactive

Git rebase interactive è quando git rebase accetta un argomento -- i. Questo sta per ” Interattivo.”Senza argomenti, il comando viene eseguito in modalità standard. In entrambi i casi, supponiamo di aver creato un ramo di funzionalità separato.,

 # Create a feature branch based off of master git checkout -b feature_branch master # Edit files git commit -a -m "Adds new feature" 

Git rebase in modalità standard prenderà automaticamente i commit nel tuo ramo di lavoro corrente e li applicherà alla testa del ramo passato.

 git rebase 

Questo rebases automaticamente il ramo corrente su, che può essere qualsiasi tipo di riferimento di commit (ad esempio un ID, un nome di ramo, un tag o un riferimento relativo aHEAD).

L’esecuzione digit rebase con il flag-i inizia una sessione di rebasing interattiva., Invece di spostare ciecamente tutti i commit nella nuova base, il rebasing interattivo ti dà l’opportunità di modificare i singoli commit nel processo. Ciò consente di ripulire la cronologia rimuovendo, suddividendo e modificando una serie esistente di commit. È come Git commit --amend sugli steroidi.

 git rebase --interactive 

Questo rebases il ramo corrente su ma utilizza una sessione di rebasing interattiva. Si apre un editor in cui è possibile inserire i comandi (descritti di seguito) per ogni commit da rebased., Questi comandi determinano come i singoli commit verranno trasferiti alla nuova base. Puoi anche riordinare l’elenco dei commit per modificare l’ordine dei commit stessi. Una volta specificati i comandi per ogni commit nella rebase, Git inizierà a riprodurre i commit applicando i comandi rebase. I comandi di modifica del rebasing sono i seguenti:

Comandi di rebase aggiuntivi

Come dettagliato nella pagina della cronologia di riscrittura, il rebasing può essere utilizzato per modificare commit precedenti e multipli, file impegnati e più messaggi., Mentre queste sono le applicazioni più comuni, git rebase ha anche opzioni di comando aggiuntive che possono essere utili in applicazioni più complesse.

• git rebase -- d significa che durante la riproduzione il commit verrà scartato dal blocco di commit finale combinato.
• git rebase -- p lascia il commit così com’è. Non modificherà il messaggio o il contenuto del commit e sarà comunque un commit individuale nella cronologia dei rami.
• git rebase -- x durante la riproduzione esegue uno script di shell della riga di comando su ogni commit contrassegnato., Un esempio utile potrebbe essere quello di eseguire la suite di test di codebase su commit specifici, che possono aiutare a identificare le regressioni durante una rebase.

Recap

Il rebasing interattivo ti dà il controllo completo su come appare la cronologia del tuo progetto. Ciò offre molta libertà agli sviluppatori, in quanto consente loro di commettere una storia “disordinata” mentre sono concentrati sulla scrittura di codice, quindi tornare indietro e ripulirlo dopo il fatto.

La maggior parte degli sviluppatori ama usare un rebase interattivo per lucidare un ramo di funzionalità prima di fonderlo nella base di codice principale., Questo dà loro l’opportunità di schiacciare commit insignificanti, eliminare quelli obsoleti e assicurarsi che tutto il resto sia in ordine prima di impegnarsi nella cronologia del progetto “ufficiale”. Per tutti gli altri, sembrerà che l’intera funzionalità sia stata sviluppata in una singola serie di commit ben pianificati.

Il vero potere del rebasing interattivo può essere visto nella cronologia del ramo master risultante. Per tutti gli altri, sembra che tu sia un brillante sviluppatore che ha implementato la nuova funzionalità con la quantità perfetta di commit la prima volta., Questo è il modo in cui il rebasing interattivo può mantenere la cronologia di un progetto pulita e significativa.

Opzioni di configurazione

Ci sono alcune proprietà di rebase che possono essere impostate usandogit config. Queste opzioni modificheranno l’aspetto dell’outputgit rebase.

• rebase.stat: Un booleano impostato su false per impostazione predefinita. L’opzione commuta la visualizzazione del contenuto diffstat visivo che mostra cosa è cambiato dall’ultima degradazione.

• rebase.autoSquash: Un valore booleano che commuta il comportamento--autosquash.,

• rebase.missingCommitsCheck: Può essere impostato su più valori che cambiano il comportamento di rebase attorno ai commit mancanti.,/tr>

  error

  Stops the rebase and prints removed commit warning messages

  ignore

  Set by default this ignores any missing commit warnings
  • rebase.instructionFormat: A git log format string that will be used for formatting interactive rebase display

  Advanced rebase application

  The command line argument --onto can be passed to git rebase., Quando in modalità git rebase--onto il comando si espande in:

    git rebase --onto 

  Il comando--onto abilita una forma o una rebase più potente che consente di passare riferimenti specifici come punte di una rebase.
  Diciamo che abbiamo un repository di esempio con rami come:

    o---o---o---o---o master \ o---o---o---o---o featureA \ o---o---o featureB 

  featureB è basato su featureA, tuttavia, ci rendiamo conto che featureB non dipende da nessuna delle modifiche in featureA e potrebbe essere semplicemente ramificato dal master.

    git rebase --onto master featureA featureB 

  featureA è il ., master diventa e featureB è riferimento per ciò a cui punteràHEAD di. I risultati sono quindi:

    o---o---o featureB / o---o---o---o---o master \ o---o---o---o---o featureA 

  Comprendere i pericoli di rebase

  Un avvertimento da considerare quando si lavora con Git Rebase è che i conflitti di unione possono diventare più frequenti durante un flusso di lavoro di rebase. Ciò si verifica se si dispone di un ramo longevo che si è allontanato dal master., Alla fine vorrai rebase contro master e in quel momento potrebbe contenere molti nuovi commit con cui le modifiche del tuo ramo potrebbero entrare in conflitto. Questo è facilmente risolvibile ribattezzando frequentemente il tuo ramo contro il master e facendo commit più frequenti. Gli argomenti della riga di comando --continue e --abort possono essere passati a git rebase per avanzare o reimpostare la rebase quando si affrontano conflitti.

  Un avvertimento di rebase più serio è perso commit dalla riscrittura interattiva della cronologia., L’esecuzione di rebase in modalità interattiva e l’esecuzione di sottocomandi come squash o drop rimuoveranno i commit dal registro immediato della tua branche. A prima vista questo può apparire come se i commit fossero definitivamente spariti. Usando git reflog questi commit possono essere ripristinati e l’intera rebase può essere annullata. Per maggiori informazioni sull’utilizzo di git reflog per trovare i commit persi, visita la nostra pagina di documentazione Git reflog.

  Git Rebase stesso non è seriamente pericoloso., I veri casi di pericolo sorgono quando si esegue la riscrittura della cronologia dei rebase interattivi e si forzano a spingere i risultati su un ramo remoto condiviso da altri utenti. Questo è un modello che dovrebbe essere evitato in quanto ha la capacità di sovrascrivere il lavoro di altri utenti remoti quando tirano.

  Ripristino da rebase upstream

  Se un altro utente ha rebased e forza spinto al ramo a cui si sta commettendo, ungit pull sovrascriverà tutti i commit che si sono basati su quel ramo precedente con il suggerimento che è stato forzato., Fortunatamente, usandogit reflog puoi ottenere il reflog del ramo remoto. Sul reflog del ramo remoto è possibile trovare un ref prima che fosse rebased. Puoi quindi rebase il tuo ramo contro quel riferimento remoto usando l’opzione--onto come discusso sopra nella sezione dell’applicazione Rebase avanzata.

  Sommario

  In questo articolo abbiamo coperto git rebase utilizzo. Abbiamo discusso casi d’uso di base e avanzati ed esempi più avanzati., Alcuni punti chiave della discussione sono:

  • git rebase standard vs modalità interattive
  • git rebase opzioni di configurazione
  • git rebase reb su
  • git rebase perso commit