Risolvere i conflitti di merge Git visualmente — guida passo passo

Perché i conflitti di merge spaventano gli sviluppatori (e perché non dovrebbero)

Se hai usato Git per un qualsiasi periodo di tempo, quasi certamente ti sei imbattuto nel temuto conflitto di merge. Quel momento in cui Git ti dice che non riesce a unire automaticamente le tue modifiche può sembrare come sbattere contro un muro. Molti sviluppatori, specialmente quelli all'inizio della loro carriera, trattano i conflitti di merge come qualcosa che è andato storto. Ma la verità è più semplice: i conflitti di merge sono una parte normale dello sviluppo collaborativo. Hanno solo bisogno dell'approccio giusto per essere risolti in modo efficiente.

Cos'è un conflitto di merge?

Un conflitto di merge si verifica quando Git non riesce a combinare automaticamente le modifiche da due branch diversi. Questo accade tipicamente quando due persone (o anche la stessa persona su branch diversi) modificano le stesse righe nello stesso file.

Quando Git rileva un conflitto, inserisce dei marcatori di conflitto direttamente nei file interessati:

<<<<<<< HEAD
const timeout = 5000;
=======
const timeout = 10000;
>>>>>>> feature/update-timeout

Tutto ciò che si trova tra <<<<<<< HEAD e ======= è la tua versione (spesso chiamata "ours"). Tutto ciò che si trova tra ======= e >>>>>>> è la versione in arrivo ("theirs"). Il tuo compito è decidere quale deve essere il risultato finale, rimuovere i marcatori e comunicare a Git che il conflitto è risolto.

Il modo tradizionale: modificare i marcatori di conflitto a mano

L'approccio più elementare è aprire il file in conflitto in un editor di testo, trovare ogni set di marcatori di conflitto e modificare manualmente il codice. Per un singolo conflitto in un file piccolo, funziona bene. Ma diventa rapidamente faticoso quando hai a che fare con:

• Conflitti multipli sparsi in un singolo file
• Diversi file in conflitto nello stesso merge
• Modifiche complesse dove devi combinare parti di entrambe le versioni
• Conflitti annidati o adiacenti dove i marcatori sono difficili da leggere

Modificare i marcatori manualmente è soggetto a errori. È facile lasciare accidentalmente un marcatore, cancellare il blocco sbagliato o introdurre un bug sottile perché hai perso traccia di cosa ogni versione stava cercando di fare. Ci deve essere un modo migliore.

Il modo visuale: usare un editor di merge a 3 vie

Cos'è un merge a 3 vie?

Un merge a 3 vie ti mostra tre versioni del file contemporaneamente:

• Base -- l'antenato comune, ovvero la versione del file prima che uno dei due branch apportasse modifiche
• Ours -- la versione del file nel tuo branch
• Theirs -- la versione del file nel branch in arrivo

Avere tutte e tre le versioni visibili contemporaneamente è un punto di svolta. Invece di fissare i marcatori di conflitto e cercare di ricostruire cosa è successo, puoi vedere esattamente cosa ha modificato ciascun lato rispetto all'originale. Questo contesto rende molto più facile decidere come risolvere ogni conflitto.

Come funziona in GitSquid

GitSquid include un editor di merge a 3 vie integrato, progettato per rendere la risoluzione dei conflitti semplice, anche se non hai mai risolto un conflitto prima. Ecco come si presenta il flusso di lavoro:

1. Vedere tutti i file in conflitto a colpo d'occhio. Quando un merge produce conflitti, il pannello dei conflitti elenca ogni file interessato. Sai immediatamente la portata di ciò che deve essere risolto.

2. Aprire l'editor a 3 vie. Clicca su qualsiasi file in conflitto per aprirlo nell'editor di merge. Vedrai tre colonne affiancate: Base a sinistra, Ours al centro e Theirs a destra. Ogni colonna mostra il contenuto completo del file con evidenziazione della sintassi, così puoi leggere il codice nel contesto.

3. Risolvere i conflitti blocco per blocco. Ogni conflitto è evidenziato e presentato come un blocco distinto. Per ogni conflitto, hai pulsanti di azione chiari:

• Use Ours -- mantenere la tua versione del codice in conflitto
• Use Theirs -- accettare invece la versione in arrivo
• Use Both -- includere entrambe le modifiche, una dopo l'altra

Un clic e il conflitto è risolto. Niente ricerca di marcatori, nessun rischio di cancellare accidentalmente le righe sbagliate.

4. Perfezionare il risultato. Sotto le tre colonne, un pannello del risultato mostra l'output unito in un editor di codice completo alimentato da CodeMirror 6 con evidenziazione della sintassi. Se nessuna delle opzioni a un clic produce esattamente ciò di cui hai bisogno, puoi modificare il risultato direttamente. Questo è utile quando devi combinare parti di entrambe le versioni in modo personalizzato, come mantenere la firma di una funzione da un branch ma l'implementazione da un altro.

5. Contrassegnare come risolto. Una volta soddisfatto del risultato, contrassegna il file come risolto e passa al file in conflitto successivo. Quando ogni file è risolto, puoi completare il merge.

Il vantaggio chiave è che non perdi mai il contesto. Puoi sempre vedere come appariva il codice prima che uno dei branch lo toccasse, cosa ha modificato ciascun branch e quale sarà il risultato finale. Questa chiarezza elimina la maggior parte dell'ansia legata ai conflitti di merge.

Consigli per evitare i conflitti di merge

Anche con buoni strumenti, prevenire i conflitti è sempre meglio che risolverli. Ecco alcune abitudini pratiche che aiutano:

• Fai pull spesso. Più a lungo aspetti senza integrare le modifiche dal branch principale, più il tuo codice diverge dal lavoro dei tuoi colleghi. Fare pull regolarmente mantiene il divario piccolo e riduce la possibilità di modifiche sovrapposte.
• Mantieni i branch di breve durata. Un branch di feature che vive per due settimane accumula molti più conflitti potenziali rispetto a uno che vive per due giorni. Suddividi le funzionalità grandi in incrementi più piccoli e integrabili.
• Comunica con il tuo team. Se due persone devono lavorare sullo stesso file o modulo, un rapido avviso può risparmiare tempo in seguito. La coordinazione non deve essere formale; un breve messaggio è spesso sufficiente.
• Usa i feature flags. Invece di mantenere un branch di lunga durata per una funzionalità che non è pronta per il rilascio, integrala dietro un feature flag. Il codice viene integrato continuamente, ma la funzionalità rimane nascosta fino a quando non è completa.

I conflitti di merge sono normali

I conflitti di merge non sono un segno che qualcosa è andato storto. Sono una conseguenza naturale del fatto che più persone lavorano sulla stessa base di codice, che è esattamente ciò per cui il controllo di versione è progettato. La differenza tra un'esperienza frustrante e una fluida di solito si riduce agli strumenti che usi.

Un editor visuale di merge a 3 vie elimina le congetture. Invece di decifrare marcatori di conflitto in un editor di testo, vedi ogni versione del codice, scegli la risoluzione che ha senso e vai avanti. Con l'editor di merge integrato di GitSquid, risolvere i conflitti diventa semplicemente un'altra parte del flusso di lavoro, anziché qualcosa da temere.