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 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.
materiale correlato
Registro Git avanzato
Scopri la soluzione
Impara a utilizzare Git con Bitbucket Cloud
Ricorsiva
git merge -s recursive branch1 branch2Funziona 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 branch2Può 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 branchNLa 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 branchNLa 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 branchBQuesta è 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.
oursDa 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.
theirsL'opposto della strategia «nostra». L'opzione «loro» favorisce la fusione estranea nella risoluzione dei conflitti.
patienceQuesta 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-algorithimignore-*
ignore-space-change
ignore-all-space
ignore-space-at-eol
ignore-cr-at-eolUna serie di opzioni che hanno come target i caratteri degli spazi bianchi. Qualsiasi riga che corrisponde al sottoinsieme dell'opzione passata verrà ignorata.
renormalizeQuesta 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-normalizeDisattiva l'opzione di rinormalizzazione. Questo sostituisce la variabile di configurazione merge.renormalize.
no-renamesQuesta opzione ignorerà i file rinominati durante la fusione.
find-renames=nQuesto è 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%.
subtreeQuesta 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
Argomento successivo
Letture consigliate
Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.
Blog di Bitbucket
Percorso di apprendimento DevOps
