Close

Opzioni ed esempi della strategia di fusione Git

Quando un lavoro è completo, testato e pronto per essere incorporato nuovamente nella linea di sviluppo principale, il tuo team deve fare alcune scelte politiche. Quali sono le tue opzioni per la strategia di fusione? In questo articolo esamineremo le possibilità e poi forniremo alcune note su come funziona Atlassian. Spero che alla fine avrai gli strumenti per decidere cosa funziona meglio per il tuo team.


Strategie di merge di Git


Si verifica una fusione quando si combinano due branch. Git richiederà due (o più) puntatori di commit e cercherà di trovare un commit di base comune tra loro. Git ha diversi metodi per trovare un commit di base, questi metodi sono chiamati "strategie di fusione". Una volta trovato un commit di base comune, Git crea un nuovo "commit di fusione" che unisce le modifiche di ogni sequenza di commit di fusione in coda. Tecnicamente, un commit di fusione è un normale commit che ha solo due commit principali.

Git merge

git merge selezionerà automaticamente una strategia di fusione se non diversamente specificato. Ai comandi git merge e git pull può essere passata l'opzione -s (strategia). L'opzione -s può essere aggiunta al nome della strategia di fusione desiderata. Se non specificato esplicitamente, Git selezionerà la strategia di fusione più appropriata in base ai branch forniti. Di seguito è riportato un elenco delle strategie di fusione disponibili.

Finestra della console
materiale correlato

Registro Git avanzato

Logo di Bitbucket
Scopri la soluzione

Impara a utilizzare Git con Bitbucket Cloud

Ricorsiva

git merge -s recursive branch1 branch2

Funziona su due head. Ricorsiva è la strategia di fusione predefinita quando si estrae o si unisce un branch. Inoltre, può rilevare e gestire le fusioni che coinvolgono le ridenominazioni, ma al momento non può utilizzare le copie rilevate. Questa è la strategia di fusione predefinita quando si estrae o si unisce un branch.

Risoluzione

git merge -s resolve branch1 branch2

Può risolvere solo due head che utilizzano un algoritmo di fusione a 3 vie. Cerca di rilevare attentamente le ambiguità di fusione incrociata ed è considerato generalmente sicuro e veloce.

Multipla

git merge -s octopus branch1 branch2 branch3 branchN

La strategia di fusione predefinita per più di due head. Quando viene passato più di un branch, la strategia multipla si attiva automaticamente. Se un'unione presenta conflitti che richiedono una risoluzione manuale, la strategia multipla rifiuterà il tentativo di fusione. Viene utilizzata principalmente per raggruppare head di branch con funzionalità simili.

Nostra

git merge -s ours branch1 branch2 branchN

La strategia Nostra opera su più branch N. Il risultato dell'unione in uscita è sempre quello del HEAD del branch attuale. Il termine "nostra" implica che la preferenza ignori di fatto tutte le modifiche da tutti gli altri branch. È pensata per essere utilizzata per combinare la cronologia di branch di funzionalità simili.

Sottoalbero

git merge -s subtree branchA branchB

Questa è un'estensione della strategia ricorsiva. Quando si uniscono A e B, se B è un sottoalbero figlio di A, B viene aggiornato innanzitutto per riflettere la struttura ad albero di A, questo aggiornamento viene apportato anche all'albero predecessore comune condiviso tra A e B.

Tipi di strategie di fusione Git


Fusioni esplicite

Le fusioni esplicite sono il tipo di fusione predefinito. La parola «esplicite» indica che creano un nuovo commit di fusione. Questo altera la cronologia dei commit e mostra esplicitamente dove è stata eseguita la fusione. Il contenuto del commit di fusione è anche esplicito per il fatto che mostra quali commit erano i padri del commit di fusione. Alcuni team evitano le fusioni esplicite perché probabilmente i commit di fusione aggiungono "rumore" alla cronologia del progetto.

fusione implicita tramite rebase o fusione con avanzamento rapido

Squash durante la fusione, generalmente senza una fusione esplicita

Opzioni di strategia di fusione Git ricorsiva


La strategia «ricorsiva» introdotta in precedenza ha un proprio sottoinsieme di opzioni operative aggiuntive.

ours

Da non confondere con la strategia di fusione Nostra. Questa opzione è un conflitto da risolvere automaticamente senza problemi privilegiando la versione «nostra». Le modifiche dal lato «loro» vengono incorporate automaticamente se non sono in conflitto.

theirs

L'opposto della strategia «nostra». L'opzione «loro» favorisce la fusione estranea nella risoluzione dei conflitti.

patience

Questa opzione impiega più tempo per evitare fusioni errate su righe corrispondenti non importanti. Questa opzione è utilizzata al meglio quando i branch da unire sono estremamente divergenti.

diff-algorithim
ignore-*

    ignore-space-change
    ignore-all-space
    ignore-space-at-eol
    ignore-cr-at-eol

Una serie di opzioni che hanno come target i caratteri degli spazi bianchi. Qualsiasi riga che corrisponde al sottoinsieme dell'opzione passata verrà ignorata.

renormalize

Questa opzione esegue il check-out e il check-in su tutti gli alberi git tree risolvendo una fusione a tre vie. Questa opzione è pensata per essere utilizzata per unire branch con stati di check-in e check-out diversi.

no-normalize

Disattiva l'opzione di rinormalizzazione. Questo sostituisce la variabile di configurazione merge.renormalize.

no-renames

Questa opzione ignorerà i file rinominati durante la fusione.

find-renames=n

Questo è il comportamento predefinito. La fusione ricorsiva rispetterà le ridenominazioni dei file. Il parametro n può essere usato per superare una soglia di somiglianza tra ridenominazioni. Il valore predefinito n è 100%.

subtree

Questa opzione prende in prestito la strategia "subtree". Se la strategia opera su due alberi e modifica il modo in cui farli corrispondere a un predecessore condiviso, questa opzione opera invece sui metadati del percorso dell'albero per farli corrispondere.

La nostra politica di fusione Git


Atlassian preferisce fortemente l'uso di fusioni esplicite. Il motivo è molto semplice: le fusioni esplicite offrono un'ottima tracciabilità e contesto sulle funzionalità da unire. Un rebase per la pulizia della cronologia locale prima di condividere una sezione di funzionalità per la revisione è assolutamente incoraggiato, ma ciò non cambia affatto la politica. La estende.


Condividi l'articolo

Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Le persone collaborano utilizzando una parete piena di strumenti

Blog di Bitbucket

Illustrazione su Devops

Percorso di apprendimento DevOps

Funzione Demo Den per demo con esperti Atlassian

Come Bitbucket Cloud funziona con Atlassian Open DevOps

Iscriviti alla nostra newsletter DevOps

Thank you for signing up