La maggior parte delle integrazioni di codice avviene con una fusione, ma occasionalmente uno sviluppatore vuole ottenere il proprio codice locale raggiunto con il ramo master attraverso un rebase invece. In questo esempio dimostreremo come git rebase un ramo da master invece di usare il comando merge, sottolineando anche l’impatto dell’esecuzione di un’operazione git rebase to master.
Cosa significa Git rebase to master?,
In questo tutorial, prenderemo il ramo chiamato sviluppare e rebase sulla punta del master.
Il ramo di sviluppo si è interrotto dal master al commit C, quindi entrambi i rami condividono i file a.html, b.html e c.html. Vedere l’immagine qui sotto per aiutare a visualizzare questo.
Dal momento che si è verificato il ramo, master ha aggiunto commit D ed E. Ciò significa che master ha due file che lo sviluppo non ha, vale a dire d.html e e.html.,
Questo è il modo in cui il repository Git appare prima di una rebase git da master.
Inoltre, dopo la divisione, ci sono stati due nuovi commit sul ramo di sviluppo, aggiungendo i file f.html e g.html. Questi sono file che il ramo di sviluppo ha che il ramo master non lo fa.
Questo è il modo in cui il repository GitLab si occupa della rebase git da master.,
Impatto della rebase Git
Dopo un ramo di sviluppo riuscito a master rebase:
- I file nel ramo master non cambieranno
- Il ramo di sviluppo acquisirà inoltre tutti i nuovi file del ramo master
- Il punto del ramo di sviluppo cambierà.
- Apparirà come se il ramo di sviluppo si dividesse dopo il commit E sul ramo master.
- Prima della rebase, il ramo di sviluppo si divide dal master al commit C.,
Git rebase to master sintassi del comando
L’operazione per eseguire una rebase Git da master è semplice. Basta aggiungere alla fine del comando il nome del ramo di origine e quindi il nome del ramo da rebase. Per rebase sviluppare per padroneggiare il comando è il seguente:
git rebase master develop
Attenzione: C’è un git rebase su switch che a volte gli sviluppatori credono erroneamente di dover includere con il comando rebase. In questo modo causerà commit da scartare e file da perdere., Non commettere l’errore di eseguire un rebase git sull’operazione.
Prima della rebase, il ramo di sviluppo aveva solo cinque file.
Ogni ramo ha cinque file prima della rebase git per l’operazione master.
Dopo il rebase Git da master, il ramo di sviluppo ha sette file. Ha mantenuto tutti i suoi file originali e ha acquisito due nuovi file dalla punta del ramo master., Tuttavia, il numero di file nel ramo master rimane invariato.
Dopo il rebase git di develop to master, il ramo develop acquisisce tutti i file master.
Il fatto che il ramo master non abbia acquisito alcun file dal ramo develop spesso elimina i nuovi utenti Git, ma questo è il comportamento previsto. Una rebase git non si sincronizza tra i rami. Cattura semplicemente un ramo con le ultime modifiche da un altro.,
Il numero di file in sviluppo aumenta dopo la rebase git al master.
Procedere con cautela
Quando si verifica una rebase Git, la cronologia di commit del repository viene irrimediabilmente modificata. Dopo il rebase nel nostro esempio, i commit F e G vengono assegnati nuovi ID commit e i vecchi ID commit vengono scartati. Per questo motivo, vedrai spesso commit rebasati contrassegnati come F ‘e G’ per sottolineare il fatto che sono stati assegnati nuovi ID commit.,
Se rebase un ramo condiviso con un altro sviluppatore e spingere le modifiche di nuovo a GitHub o GitLab, un collega sviluppatore si imbatterà in una varietà o problemi quando tentano di tirare il repository rebased nel loro ambiente di sviluppo locale. I commit che hanno localmente saranno scomparsi sul telecomando e il ramo remoto avrà una cronologia dei rami incompatibile. Come puoi immaginare, il rebasing di un ramo condiviso o lo schiacciamento dei commit Git possono causare havok.,
Rebase a GitHub o GitLab
Infatti, se si rebase e provare a spingere a GitLab o GitHub, il server non permetterà l’operazione da eseguire. Per rebase a GitHub o GitLab, uno sviluppatore deve aggiungere l’interruttore-force al comando git push per costringere le modifiche da accettare.
git push origin --force
Una rebase GitLab o GitHub la spinta sarà respinta a meno che non sia forzata.,
La logica accettata è solo git rebase per padroneggiare i rami locali del tuo spazio di lavoro personale. In questo modo i tuoi comandi di pulizia Git non influiscono su nessun altro. Non eseguire un rebase git da master su rami condivisi con altri sviluppatori. Un rebase sul master va bene, ma non il contrario. Altrimenti è probabile che si rompa la build e le operazioni push o pull verranno messe in stand-by, ostacolando lo sviluppo continuo e rendendoti persona non grata con il resto degli sviluppatori e del team DevOps.