Un’introduzione a Git merge e rebase: cosa sono e come usarli

Vali Shah

Come Sviluppatore, molti di noi devono scegliere tra Unione e Rebase. Con tutti i riferimenti che otteniamo da Internet, tutti credono “Non usare Rebase, potrebbe causare seri problemi.”Qui spiegherò cosa sono merge e rebase, perché dovresti (e non dovresti) usarli e come farlo.

Git Merge e Git Rebase servono allo stesso scopo. Sono progettati per integrare le modifiche da più rami in uno., Sebbene l’obiettivo finale sia lo stesso, questi due metodi lo raggiungono in modi diversi ed è utile conoscere la differenza man mano che diventi uno sviluppatore di software migliore.

Questa domanda ha diviso la comunità Git. Alcuni credono che si dovrebbe sempre rebase e altri che si dovrebbe sempre unire. Ogni lato ha alcuni vantaggi convincenti.

Git Merge

La fusione è una pratica comune per gli sviluppatori che utilizzano sistemi di controllo di versione. Sia che i rami siano creati per test, correzioni di bug o altri motivi, l’unione impegna le modifiche in un’altra posizione., Per essere più specifici, l’unione prende il contenuto di un ramo di origine e li integra con un ramo di destinazione. In questo processo, viene modificato solo il ramo di destinazione. La cronologia del ramo sorgente rimane la stessa.,da2a4595a”>

Pro

• Semplice e familiare
• Mantiene la storia completa e in ordine cronologico
• Mantiene la contesto del ramo

Contro

• Commit storia può diventare inquinata da un sacco di unione si impegna
• Debug utilizzando git bisect può diventare più difficile

Come fare

Unire il ramo master in funzione di ramo con il checkout e merge i comandi.,

$ git checkout feature$ git merge master(or)$ git merge master feature

Questo creerà un nuovo “Merge commit” nel ramo feature che contiene la cronologia di entrambi i rami.

Git Rebase

Rebase è un altro modo per integrare le modifiche da un ramo all’altro. Rebase comprime tutte le modifiche in una singola ” patch.”Quindi integra la patch sul ramo di destinazione.

A differenza della fusione, la rebasing appiattisce la cronologia perché trasferisce il lavoro completato da un ramo all’altro. Nel processo, la cronologia indesiderata viene eliminata.,

Rebases sono come i cambiamenti dovrebbero passare dalla cima della gerarchia verso il basso, e unioni sono come scorrono verso l’alto

Pro

• Semplifica potenzialmente complessa storia
• la Manipolazione di un singolo commit è facile (ad es., di rimuoverli)
• Evita di unione commit “rumore” in occupato repos piena di rami
• Pulisce intermedio commette da fare un commit, il che può essere utile per DevOps team

Contro

• Bloccare la funzione in una manciata di commit può nascondere il contesto
• la Riassegnazione di depositi pubblici, può essere pericoloso quando si lavora come una squadra
• È più lavoro: con rebase per mantenere la vostra caratteristica ramo sempre aggiornato
• la Riassegnazione con telecomando rami richiede la forza di spingere., Il problema più grande che le persone affrontano è che forzano il push ma non hanno impostato il git push predefinito. Ciò si traduce in aggiornamenti a tutti i rami con lo stesso nome, sia localmente che in remoto, e questo è terribile da affrontare.

Se si rebase in modo errato e involontariamente riscrivere la storia, può portare a problemi seri, in modo da assicurarsi di sapere cosa si sta facendo!

Come farlo

Rebase il ramo feature sul ramo master utilizzando i seguenti comandi.,

$ git checkout feature$ git rebase master

Questo sposta l’intero ramo feature sopra il ramo master. Lo fa riscrivendo la cronologia del progetto creando nuovi commit per ogni commit nel ramo originale (feature).

Rebasing interattivo

Ciò consente di modificare i commit man mano che vengono spostati nel nuovo ramo. Questo è più potente di rebase automatizzato, in quanto offre il controllo completo sulla cronologia di commit del ramo. In genere questo viene utilizzato per ripulire una cronologia disordinata prima di unire un ramo di funzionalità in master.,

$ git checkout feature$ git rebase -i master

Questo aprirà l’editor elencando tutti i commit che stanno per essere spostati.

pick 22d6d7c Commit message#1pick 44e8a9b Commit message#2pick 79f1d2h Commit message#3

Questo definisce esattamente come apparirà il ramo dopo aver eseguito la rebase. Riordinando le entità, puoi rendere la cronologia simile a quella che vuoi. Ad esempio, è possibile utilizzare comandi come fixup, squash, edit ecc., al posto di pick.

Quale usare

Quindi cosa c’è di meglio?, Cosa raccomandano gli esperti?

È difficile generalizzare e decidere su uno o l’altro, poiché ogni squadra è diversa. Ma dobbiamo iniziare da qualche parte.

I team devono prendere in considerazione diverse domande quando impostano le loro politiche Git rebase vs. merge. Perché, a quanto pare, una strategia di flusso di lavoro non è migliore dell’altra. Dipende dalla tua squadra.

Considera il livello di rebasing e competenza Git in tutta l’organizzazione. Determina il grado in cui apprezzi la semplicità del rebasing rispetto alla tracciabilità e alla cronologia della fusione.,

Infine, le decisioni sulla fusione e rebasing dovrebbero essere considerate nel contesto di una chiara strategia di ramificazione (fare riferimento a questo articolo per capire di più sulla strategia di ramificazione). Una strategia di ramificazione di successo è progettata attorno all’organizzazione dei tuoi team.

Cosa consiglio?

Man mano che il team cresce, diventerà difficile gestire o tracciare le modifiche allo sviluppo con una politica di unione sempre. Per avere una cronologia di commit pulita e comprensibile, l’uso di Rebase è ragionevole ed efficace.,

Considerando le seguenti circostanze e linee guida, puoi ottenere il meglio da Rebase:

• Stai sviluppando localmente: Se non hai condiviso il tuo lavoro con nessun altro. A questo punto, si dovrebbe preferire rebasing sulla fusione per mantenere la vostra storia ordinata. Se hai il tuo fork personale del repository e non è condiviso con altri sviluppatori, sei sicuro di rebase anche dopo aver spinto al tuo ramo.
• Il tuo codice è pronto per la revisione: hai creato una richiesta pull. Altri stanno rivedendo il tuo lavoro e potenzialmente lo stanno recuperando nel loro fork per la revisione locale., A questo punto, non dovresti ribasare il tuo lavoro. Dovresti creare commit ‘rework’ e aggiornare il tuo ramo di funzionalità. Questo aiuta con la tracciabilità nella richiesta di pull e previene la rottura accidentale della storia.
• La revisione è fatta e pronta per essere integrata nel ramo di destinazione. Felicitazioni! Stai per eliminare il tuo ramo di funzionalità. Dato che altri sviluppatori non si uniranno a questi cambiamenti da questo punto in poi, questa è la tua occasione per disinfettare la tua cronologia., A questo punto, puoi riscrivere la cronologia e piegare i commit originali e quei fastidiosi ‘pr rework’ e ‘merge’ commit in un piccolo set di commit focalizzati. La creazione di un’unione esplicita per questi commit è facoltativa, ma ha valore. Registra quando la funzione si è laureata per padroneggiare.

Conclusione

Spero che questa spiegazione abbia dato alcune intuizioni su Git merge e Git rebase. La strategia Merge vs rebase è sempre discutibile. Ma forse questo articolo ti aiuterà a dissipare i tuoi dubbi e ti permetterà di adottare un approccio che funzioni per la tua squadra.